Re: encfs, pam_mount, fusermount failed

[mireero <mireero@free.fr>]

On 05/14/2015 12:10 PM, ps wrote:
> j'ai bien l'impression de n'avoir pas compris grand chose à l'option
> "user":)

Excuse moi, c'est vrai que j'ai pas été très précis.
Je te parle d'un point de vue général à propos de "monter" un volume, je 
n'ai jamais utilisé pam_mount (si y'a un expert ici je cède la main).

> au re-démarrage, le montage se fait, le pam_mount.conf.xml est modifié
> dans la ligne "volume user" et j'essaye plusieurs ENCFS6_CONFIG avec ces
> 'magnifiques' échecs:)  :
>
> ~$ cat /proc/mounts
> ....
> fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
> encfs /home/jlg/zaclys_o fuse.encfs
> rw,nosuid,nodev,relatime,user_id=1027,group_id=1001,default_permissions 0 0
>
> dans le pam_mount.conf.xml :
>
> <volume user="jlg" fstype="fuse"
> path="encfs#/home/%(USER)/owncloud/zaclys_f/"
> mountpoint="/home/%(USER)/zaclys_o" />
>
>
> $ ENCFS6_CONFIG=/home/$USER/coffre/.encfs6.xml encfs -o nonempty
> /home/$USER/zaclys_o
> 11:29:45 (main.cpp:356) Un ou plusieurs arguments manquants, abandon.

J'ai 3 remarques:

1 - Quand je monte un système de fichier et que j'ai des soucis, 
j'essaye d'abord de le monter à la main, c'est à dire directement dans 
bash, ex:
Récemment j'ai mis en place un serveur nfs sur un raspberry pi et ma 
ligne dans fstab (du client) ne fonctionnait pas, donc mes tests se 
faisaient dans bash directement:

~# mount -t nfs 192.168.1.13:/home/pi /pi

Une fois que ça fonctionnait, je savais que si ça fonctionnait pas avec 
la ligne dans fstab, ça pouvait avoir un rapport avec mes options.
Dans fstab:

192.168.1.13:/home/pi /pi nfs defaults,user,noauto,noatime          0 0

Qu'on peut tester en bash avec:
~$ mount -t nfs -o user,noauto,noatime 192.168.1.13:/home/pi /pi

Bonne transition pour:

2 - Tu vois ci-dessus que je peux monter le volume nfs en tant que 
simple utilisateur (d'où le "~"); c'est grâce à là l'option "user".
C'est de ça dont je parlais quand je mentionnais "user" puisque tes 
messages d'erreurs ressemblent à un problème de droit (mais je n'ai 
aucune idée si pam_mount connaît cette option). Par exemple (ou donc 
exécuter la commande qui va bien dans bash (qui commence peut-être par 
fusermount) et tester en root par exemple):
$ ENCFS6_CONFIG=/home/jlg/coffre/.encfs6.xml encfs -o nonempty,user
/home/jlg/zaclys_o
Tu peux aussi mettre des droits élevé à "jlg" concernant les 2 dossiers 
en question genre:
~# chown jlg:fuse /home/jlg/{zaclys_f,owncloud/zaclys_f}
~# chmod 0770 /home/jlg/{zaclys_f,owncloud/zaclys_f}
Par exemple, et juste pour voir si ça aide, ensuite tu baisses les 
droits si tu veux.

3 - Remarque facultative:
L'option nonempty me semble un peu excessive (sauf si tu te sers de 
zaclys_f lorsque le volume chiffré est démonté).
Cela donne a penser que le dossier zaclys_f n'est pas vide. Si le(s) 
fichier(s)/dossier(s) éventuellement présent dans zaclys_f n'ont rien à 
y faire (cas habituel pour un point de montage), je démonterais le 
volume pour voir et supprimer le contenu de zaclys_f.

Ce ne sont que des remarques générale, pour y voir plus clair il 
faudrait que quelqu'un qui connaît bien pam_mount et le cryptage en 
question te réponde.


--
mireero