Comment puis-je faire fonctionner la colle udisks-colle au démarrage et monter les lecteurs en tant qu'user particulier?

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 ?

Ce que j'ai essayé

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.

Solution:

  1. 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 
  2. 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.)

Commentaires sur les mesures que vous avez sockets:

  1. 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 .

  2. 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.

  3. 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.

  4. 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.