J'essaie de faire des travaux de colle-udisks sur mon Raspbian Raspberry Pi. Cela fonctionne bien si je démarre manuellement udisks-glue
via ssh. Cependant, je souhaite le démarrer automatiquement au démarrage.
Par conséquent, un script sur /etc/init.d/udisks-glue
lance le démon pour moi (selon les instructions ici ). Cela fonctionne très bien, mais les disques sont montés avec les droits root ( drwx------
). Est-il possible de faire en sorte que ce script démarre le daemon en tant qu'user pi
, pas root
?
1) Modifier le script ci-dessus, en remplaçant
DAEMON="/usr/bin/udisks-glue"
avec
DAEMON="exec su - pi -c /usr/bin/udisks-glue"
Cela n'a pas pu être exécuté.
2) Remplacer cette ligne par une reference à un script personnalisé, qui appelle ensuite exec su - pi -c /usr/bin/udisks-glue
. Lorsque je connecte des disques durs, ils ne sont pas montés. Cependant, il y a l'apparence de process fonctionnant correctement. En regardant ps aux | grep [u]disks
ps aux | grep [u]disks
, je peux voir udisks-glue
cours d'exécution comme pi
(et deux udisks-daemon
s en cours d'exécution en tant que root); Je reçois la même sortie ps
si je démarre manuellement udisks-glue
, comme ci-dessus.
3) J'ai essayé d'éditer /etc/rc.local
, en ajoutant la ligne
su pi -c "/usr/bin/udisks-glue &"
Ceci a eu le même résultat que dans (2), avec udisks-glue
fonctionnant comme pi
, mais pas fonctionnel.
4) En fonction de cette page , exécutant udisks-colle en tant que root, mais donnant des permissions de assemblys à tous. Cela fonctionne pour les filesystems FAT, mais ne parvient même pas à monter ext4. (Je préférerais que les assemblys appartiennent à l'user pi
toute façon.)
J'ai eu le même problème il y a un moment.
Corriger votre configuration: créez le file /etc/polkit-1/localauthority/50-local.d/50-mount-as-pi.pkla
avec le contenu suivant:
[Media mounting by pi] Identity=unix-user:pi Action=org.freedesktop.udisks.filesystem-mount ResultAny=yes
Correction de votre script d'initialisation:
append une variable contenant l'user que vous souhaitez exécuter udisks-glue
comme:
NAME=udisks-glue PIDFILE=/var/run/udisks.pid DAEMON="/usr/bin/udisks-glue" DAEMONUSER=pi <-- add this line
modifiez les invocations start-stop-daemon
pour utiliser la variable $DAEMONUSER
:
start) log_daemon_msg "Starting Automounter" "$NAME" --> start-stop-daemon --start --exec $DAEMON --chuid $DAEMONUSER log_end_msg $? ;; stop) log_daemon_msg "Stopping Automounter" "$NAME" --> start-stop-daemon --stop --exec $DAEMON --user $DAEMONUSER log_end_msg $? rm -f $PIDFILE ;;
(NOTE: J'ai enlevé la partie -- -p $PIDFILE
de la première invocation.) Votre count d'user habituel n'aura probablement pas d'autorisation en écriture pour /var/run
, donc vous pouvez faire ce que j'ai fait ci-dessus ou changer la variable $PIDFILE
à un path inscriptible par votre user régulier.)
Cela n'aurait pas pu fonctionner. La variable $DAEMON
est utilisée comme argument pour --exec
dans une invocation start-stop-daemon
. Cet argument devrait être un exécutable , alors que exec
est un shell embedded .
Cela a cassé votre script d'initialisation. Lors du démarrage de la udisks-glue
, l'arrêt ne serait pas comme le start-stop-daemon
essaie d'arrêter /path/to/your/helper/script.sh
au lieu du démon actuel ( /usr/bin/udisks-glue
). Mettre de côté, lorsque vous démarrez udisks-glue
en mode démon, il ne génère pas de messages de debugging. Si vous avez exécuté la command suivante dans un shell interactif:
# su pi -c "/usr/bin/udisks-glue -f"
vous verriez probablement quelque chose comme:
Device file /dev/sdb1 inserted Trying to automount /dev/sdb1... Failed to automount /dev/sdb1: Not Authorized Device file /dev/sdb inserted
ce qui aurait expliqué pourquoi vos lecteurs ne sont pas montés.
C'était effectivement la même chose que 2. Une remarque supplémentaire: l'esperluette ( &
) à la fin était redondante car la udisks-glue
udisks udisks-glue
démonise par défaut.
Encore une fois, l'exécution de udisks-glue
au premier plan aurait expliqué le problème pour les filesystems non-FAT:
Device file /dev/sdb1 inserted Trying to automount /dev/sdb1... Failed to automount /dev/sdb1: Mount option dmask=0 is not allowed Device file /dev/sdb inserted
Notez également que si vous souhaitez changer le propriétaire d'un sharepoint assembly ext4, vous devez le chown
après le assembly.