Re: encfs, pam_mount, fusermount failed

[ps <vbn2@hotmail.fr>]

donc tous les droit pour tous les 'protagonistes' :

~$ getfacl coffre/.encfs6.xml # file: coffre/.encfs6.xml
# owner: jlg
# group: fuse
user::rwx
group::rwx
other::r-x

jlg@UL30A:~$ getfacl coffre
# file: coffre
# owner: jlg
# group: fuse
user::rwx
group::rwx
other::r-x

jlg@UL30A:~$ getfacl zaclys_o/# file: zaclys_o/
# owner: jlg
# group: fuse
user::rwx
group::rwx
other::r-x

:~$ getfacl owncloud/zaclys_f/
# file: owncloud/zaclys_f/
# owner: jlg
# group: fuse
user::rwx
group::rwx
other::r-x

~$ ENCFS6_CONFIG=/home/$USER/coffre/.encfs6.xml encfs -o nonempty,user
/home/$USER/owncloud/zaclys_f /home/$USER/zaclys_o
Mot de passe :
fusermount: failed to access mountpoint /home/jlg/zaclys_o: Permission
denied


mais peut-être que encfs, une fois que pam_mount a lancé le bazar, ne
tient compte que de ce qui est inscrit dans pam_mount et que
ENCFS6_CONFIG n'est pas assez "costaud" pour "s'imposer"... :)

Le 14/05/2015 16:08, ps a écrit :
> 
> 
> Le 14/05/2015 14:51, mireero a écrit :
>> 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.
> 
> non-non, c'est moi qui ne suis pas au niveau de ce à quoi je me suis
> attaqué, pensant à la lecture bien documentée des réf données en début
> d'échange, cela n'allait être qu'une formalité... c'est beau, parfois,
> l'optimisme du débutant... :)
> bon, dans le cas présent, ça m'a bien planté ! :)
> 
>> 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
> 
> je confirme : l'étape manuelle fonctionne : le pam_mount semble aussi
> fonctionner.
> c'est le passage par ENCFS6_CONFIG qui semble bloquer l'affaire
> 
> 
>>
>> 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.
>>
> 
> ok, je vais essayer d'ajouter le 'user'
> 
> 
> 
>> 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.
> 
> les dossiers à synchroniser, ce qui est l'objectif initial, seront
> placés dans zaclys_o.
> via encfs et pam_mount, ils seront cryptés, puis owncloud-client se
> chargera de rappatrier les dossiers chiffrés sur owncloud-zaclys. enfin
> c'est ce que j'ai imaginé comme possible, un jour :)
> donc ce qui est dans zaclys_o, je pensais que ça pouvait (devait) y
> rester : certains fichiers à l'intérieur seront modifiés, peut-être
> supprimés et que owncloud-client fera le tri entre ce qu'il a déjà et ce
> qu'il doit rappatrier car nouveau ou modifié.
> mais peut-être que "je rêve d'une banque"... de données 'idéale' :)
> il est bien (sans doute) possible que je n'ai pas compris ce qu'on
> pouvait faire exactement avec owncloud et pam_mount.
> 
> 
>>
>> 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.
>>
> 
> un grand merci quand même pour le coup de main !
>