Je gère et monte un dossier chiffré avec Gnome Encfs Manager et cela a fonctionné pendant des années. Soudain, il semble que les fichiers ou les autorisations à l'intérieur aient été corrompus. Le montage fonctionne comme d'habitude sur le terminal comme avec le gestionnaire. Les fichiers du dossier racine sont également accessibles.
Mais dans tous les répertoires enfants, je ne vois que les autorisations de nom de fichier sous forme de points d'interrogation, je ne peux pas les ouvrir et même avec Sudo, je ne peux pas modifier les autorisations.
root@lubuntu:/home/user/safe# ls -l
ls: cannot access local: Permission denied
total 1932
...
d????????? ? ? ? ? ? local
local est le dossier chiffré encfs monté. Sur un shell racine je ne peux pas cd à l'intérieur, avec mon propre utilisateur je peux mais seulement obtenir à nouveau des points d'interrogation:
[~/safe/local/backup]$ ls -l
ls: cannot access index.htm: Permission denied
ls: cannot access bookmarks.html: Permission denied
total 0
d????????? ? ? ? ? ? foo/
-????????? ? ? ? ? ? index.html
-????????? ? ? ? ? ? bookmarks.htm
Ce qui est étrange, c’est que mon utilisateur puisse accéder aux fichiers de ~/safe/local/fine, mais rien dans ses sous-répertoires et root ne peut en faire encore moins. chown et chmod me donnent "Autorisation refusée" en tant que racine ou avec Sudo.
Aucun conseil? Cela suggère-t-il un disque dur défaillant? J'ai récemment mis à jour de Lubuntu 14.10 à 15.10.
Mise à jour: Voici la sortie commentée lors du montage:
[~/safe]$ encfs -f -v .local test
14:37:17 (main.cpp:559) Root directory: .local/
14:37:17 (main.cpp:560) Fuse arguments: (fg) (threaded) (keyCheck) encfs test -f -o use_ino
14:37:17 (FileUtils.cpp:174) version = 20
14:37:17 (FileUtils.cpp:177) found new serialization format
14:37:17 (FileUtils.cpp:191) Subversion = 20100713
14:37:17 (Interface.cpp:117) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
14:37:17 (SSL_Cipher.cpp:335) allocated cipher ssl/aes, keySize 32, ivlength 16
14:37:17 (Interface.cpp:117) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
14:37:17 (SSL_Cipher.cpp:335) allocated cipher ssl/aes, keySize 32, ivlength 16
14:37:17 (FileUtils.cpp:1542) useStdin: 0
EncFS Password:
14:37:22 (Interface.cpp:117) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
14:37:22 (SSL_Cipher.cpp:335) allocated cipher ssl/aes, keySize 32, ivlength 16
14:37:24 (FileUtils.cpp:1550) cipher key size = 52
14:37:24 (Interface.cpp:117) checking if nameio/block(4:0:2) implements nameio/block(3:0:0)
14:37:24 (MACFileIO.cpp:71) fs block size = 1024, macBytes = 8, randBytes = 0
14:37:24 (FileNode.cpp:116) calling setIV on (null)
14:37:24 (RawFileIO.cpp:164) getAttr error on .local/uWX6wZAqMvH5RDRMW5oIb67F8V6CoVXYZPwUf6bHbu1Ms0: No such file or directory
14:37:24 (CipherFileIO.cpp:94) in setIV, current IV = 0, new IV = 11696676665880040319, fileIV = 0
14:37:24 (DirNode.cpp:641) created FileNode for .local/uWX6wZAqMvH5RDRMW5oIb67F8V6CoVXYZPwUf6bHbu1Ms0
14:37:24 (encfs.cpp:133) getattr .local/uWX6wZAqMvH5RDRMW5oIb67F8V6CoVXYZPwUf6bHbu1Ms0
14:37:24 (RawFileIO.cpp:164) getAttr error on .local/uWX6wZAqMvH5RDRMW5oIb67F8V6CoVXYZPwUf6bHbu1Ms0: No such file or directory
14:37:24 (encfs.cpp:136) getattr error: No such file or directory
14:37:24 (MACFileIO.cpp:71) fs block size = 1024, macBytes = 8, randBytes = 0
14:37:24 (FileNode.cpp:116) calling setIV on (null)
14:37:24 (RawFileIO.cpp:164) getAttr error on .local/kbZ-jP1BAg0-VpqtlMjAKr9F: No such file or directory
14:37:24 (CipherFileIO.cpp:94) in setIV, current IV = 0, new IV = 17358762804478769995, fileIV = 0
14:37:24 (DirNode.cpp:641) created FileNode for .local/kbZ-jP1BAg0-VpqtlMjAKr9F
(continues like that...)
J'ai déjà vu ce genre d'erreurs lors des tests sur EncFS et eCryptFS, mais je ne me souvenais pas exactement de l'endroit où je l'avais vue jusqu'à présent. C'était parce que je n'avais pas la permission de lire ou de lister les fichiers dans le répertoire (les répertoires ont besoin de x
permission d'exécuter la liste des fichiers), et je pense que cela aurait pu arriver avec une erreur de déchiffrement aussi.
J'ai eu quelques problèmes avec les autorisations dans les fichiers montés/déchiffrés avant. Ils semblaient refléter uniquement les autorisations du fichier chiffré (la page de manuel EncFS l’appelait le "rootdir") et la modification des fichiers montés/déchiffrés ne semblait pas fonctionner. Peut-être que le propriétaire et les autorisations pour le "rootdir"/fichiers cryptés ne sont pas correctes? Essayez de changer les autorisations "rootdir"/encrypted afin que votre utilisateur puisse y accéder (rwx?).
Je pensais que root devrait être capable de tout lire, peu importe le contenu ... mais encfs n'a pas besoin de Sudo, et j'ai essayé un test avec un seul dossier chiffré secret
et son point de montage déchiffré open
et la même chose s'est produite:
$ ls -go
total 0
drwxr-xr-x 2 80 Nov 11 00:14 open
drwxr-xr-x 2 80 Nov 11 00:14 secret
$ Sudo ls -go
ls: cannot access open: Permission denied
total 0
d????????? ? ? ? open
drwxr-xr-x 2 80 Nov 11 00:14 secret
Ou peut-être que cela ne décrypte pas les fichiers correctement. Si vous avez une bonne sauvegarde des données, ce serait génial.
Je pense que la mise à niveau de 14.10 à 15.10 pourrait être responsable. Parfois, utiliser une version plus récente avec de vieilles données ne fonctionne pas toujours bien.
Les versions du paquet encfs
que je peux trouver sur http://packages.ubuntu.com/ sont actuellement:
in wily (15.10) est la version 1.8.1-3
in vivid (15.04) est la version 1.7.4-5
en 14h10, il n’est plus sur la page Web, était probablement de 1,7,4 ...
in trusty (14.04LTS) est la version 1.7.4-2.4ubuntu2
Ou bien, le .encfs6.xml
"fichier de configuration" peut avoir été corrompu d'une manière ou d'une autre. Essayer d’en utiliser une copie de sauvegarde pourrait fonctionner. man encfs
a quelques détails, mais semble contenir encore des références à la version 5.
J'essaierais, par ordre de préférence:
Essayez une copie de sauvegarde du fichier de configuration (.encfs6.xml
) avec une commande similaire à:
ENCFS6_CONFIG=/home/me/.encfs6.xml encfs /encryptedDir /decryptedDir
S'il n'y a pas d'erreur HD (voir syslog et peut-être même les données SMART), je ne soupçonnerais pas le HD immédiatement.