FS#54883 - [encfs] All files are gone on the second mount
Attached to Project:
Community Packages
Opened by Jakob Unterwurzacher (rfjakob) - Thursday, 20 July 2017, 07:01 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Sunday, 30 July 2017, 10:41 GMT
Opened by Jakob Unterwurzacher (rfjakob) - Thursday, 20 July 2017, 07:01 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Sunday, 30 July 2017, 10:41 GMT
|
Details
Description:
EncFS upstream maintainer here. This was kind of a horror story that unfolded at https://github.com/vgough/encfs/issues/343 : User creates EncFS filesystem, moves lots of files there. Mounts the filesystem a few days later, all files gone, empty folder. What is happening is that the tinyxml2 library in Arch Linux saves booleans as `true` and `false` strings instead of `1` and `0`. When EncFS reads the XML on a later mount, it expects a number, and both `true` and `false` will be interpreted as 0. Of course, decryption of everything will fail, and the mountpoint appears empty. As a quick fix, you can probably use this patch: https://github.com/vgough/encfs/commit/3bfaf792e62c93416210db26bada00490c48c0c1 But please test before and after if it fixes the problem with Arch Linux's tinyxml lib. Additional info: * package version(s) encfs 1.9.1-5 Steps to reproduce: encfs $PWD/a $PWD/b echo test > b/testfile fusermount -u b encfs $PWD/a $PWD/b ls b # (empty folder) |
This task depends upon
Closed by Jaroslav Lichtblau (Dragonlord)
Sunday, 30 July 2017, 10:41 GMT
Reason for closing: Implemented
Additional comments about closing: encfs 1.9.2-1 released
Sunday, 30 July 2017, 10:41 GMT
Reason for closing: Implemented
Additional comments about closing: encfs 1.9.2-1 released
There seems to be a correlation with the way of creating files in the mounted
directory. I did the following with un-/remounting after each touch command:
* Touch file1 from parent dir
* Touch file2 from inside fuse-mounted dir
* Touch file3 from parent dir
Result:
* file1 never showed up
* file2 ok
* file3 ok as well
It looks like one has to create at least one file from inside the fuse-mounted
directory with all earlier files vanishing and all later files being ok?
EDIT: It looks like unmounting right after setup and remounting works as well.
Setup: ~/.c4 mounted at ~/c4
Transcript just after setup:
New Encfs Password:
Verify Encfs Password:
_:~$ touch c4/file1
_:~$ fusermount -u c4
_:~$ encfs ~/.c4 ~/c4
EncFS Password:
_:~$ ls c4
_:~$ fusermount -u c4
_:~$ encfs ~/.c4 ~/c4
EncFS Password:
_:~$ cd c4
_:~/c4$ touch file2
_:~/c4$ cd
_:~$ fusermount -u c4
_:~$ encfs ~/.c4 ~/c4
EncFS Password:
_:~$ ls c4
file2
_:~$ touch c4/file3
_:~$ fusermount -u c4
_:~$ encfs ~/.c4 ~/c4
EncFS Password:
_:~$ ls c4
file2 file3
_:~$
All later mounts will have "uniqueIV" and "chainedNameIV" incorrectly disabled due to this bug. Files stored now get significantly weaker encryption.
1. After the initializing run of encfs (with paranoid preset) I created file1
and un-/remounted with file1 "gone" as expected.
2. Then I replaced all occurrences of "true" with "1" in .encfs6.xml by hand
and mount-cycled and file1 was back.
3. I created file2 and mount-cycled and both files where there correctly decoded.
Would this be a reliable way to recover lost files?
Would the following be a workaround in general and compatible with the fix?
1. Initialize with encfs DIR MOUNTPOINT
2. fusermount -u
3. Replace true/false booleans with 1/0 in DIR/.encfs6.xml
4: Continue using encfs DIR MOUNTPOINT as if nothing had happened.
As for the workaround, I think you should apply the patch https://github.com/vgough/encfs/commit/3bfaf792e62c93416210db26bada00490c48c0c1 .