I got errors "transport endpoint not connected" when opening files. dmesg had: encfs[25279]: segfault at 0 ip 00007f7213f9bf36 sp 00007f72037fd970 error 4 in libencfs.so.1.9.1[7f7213f42000+75000] encfs[1833]: segfault at 0 ip 00007f0480488f36 sp 00007f047e422970 error 4 in libencfs.so.1.9.1[7f048042f000+75000] Both times this is 0x59f36 inside the library which should be function encfs::FileNode::open(int) const@@Base more precisely encfs::Lock::Lock(pthread_mutex_t &) inlined from there. I didn't see this bug with version 1.8.1-3+b3. Grüße Timo Debian Release: stretch/sid 900 testing deb.debian.org 800 unstable deb.debian.org --- Package information. --- Depends (Version) | Installed ==============================-+-============= libc6 (>= 2.14) | libfuse2 (>= 2.8) | libgcc1 (>= 1:3.3.1) | libssl1.1 (>= 1.1.0) | libstdc++6 (>= 5.2) | libtinyxml2-4 (>= 2.0.2) | debconf (>= 0.5) | OR debconf-2.0 | mount (>> 2.19.1) | fuse | Package's Recommends field is empty. Package's Suggests field is empty.
2017-01-01 13:32:15 CET Timo Weingärtner: encfs[29792]: segfault at 0 ip 00007faa1b54bee8 sp 00007faa199cb8f0 error 4 in libencfs.so.1.9.1[7faa1b4f2000+75000] This time it's 0x59ee8 in function encfs::FileNode::getAttr(stat*) const@@Base I am now reverting to that version to see if there are other changes (libc, kernel) involved. Timo
Hi Timo, I filed a similar report under #849215 but was unable to pin the issue on the encfs package. What is your underlying file system, please? Also, are you using pam_encfs.so to mount? Thank you! Best regards, Felix
Hi Felix and Timo,
I also got the same kind of errors after upgrade to 1.9.1-3.
Using encfs on top of ext4 and using pam_encfs for unlocking.
The segfault happened while heavy read on the disk (after a while doing
a backup).
Now I downgraded to 1.7.4-5 and no error.
Looking in /var/log/messages I can see (between a message and another I
rebooted and continued using the pc normally):
encfs[2507]: segfault at 0 ip b757a674 sp b09f5ea8 error 4 in
libencfs.so.1.9.1[b7524000+74000]
encfs[7025]: segfault at 0 ip b7575537 sp b01f4e48 error 4 in
libencfs.so.1.9.1[b751f000+74000]
encfs[3357]: segfault at 0 ip b7534537 sp b01f4e48 error 4 in
libencfs.so.1.9.1[b74de000+74000]
While in /var/log/debug there are loads of lines like these:
DEBUG [default] [user@unknown-host] [virtual int
encfs::RawFileIO::getAttr(stat*) const]
[/build/encfs-jKeYV6/encfs-1.9.1/encfs/RawFileIO.cpp:167] getAttr error
on
/home/.encfs/ilario/k7Brs76VtowX3IQUh7rAfzkG/YmHlRoMrZ6s3K2HlOCzt2azq/A9g,gkG5L65EZ0N6CuGuCwLN/YCLoUZolLfGmd6tr-cu1wUDM/0ci8c5mWQn94qpDKH9qwrrRt:
No such file or directory
DEBUG [default] [user@unknown-host] [int encfs::withFileNode(const
char*, const char*, fuse_file_info*,
std::function<int(encfs::FileNode*)>)]
[/build/encfs-jKeYV6/encfs-1.9.1/encfs/encfs.cpp:145] op: getattr error:
No such file or directory
DEBUG [default] [user@unknown-host] [virtual int
encfs::RawFileIO::getAttr(stat*) const]
[/build/encfs-jKeYV6/encfs-1.9.1/encfs/RawFileIO.cpp:167] getAttr error
on /home/.encfs/ilario/1UUZ5IsSKkqp7qKfFvk2BGUr: No such file or directory
DEBUG [default] [user@unknown-host] [int encfs::withFileNode(const
char*, const char*, fuse_file_info*,
std::function<int(encfs::FileNode*)>)]
[/build/encfs-jKeYV6/encfs-1.9.1/encfs/encfs.cpp:145] op: getattr error:
No such file or directory
Thanks for your help,
Ilario
Package: encfs Followup-For: Bug #849850 Jul 13 16:28:19 snowball kernel: [ 545.053729] encfs[3542]: segfault at 0 ip 00007fe2ba2d4e62 sp 00007fe2b8819960 error 4 in libencfs.so.1.9.1[7fe2ba27b000+75000] I'm running it on top of ext4, using pam_mount I've reverted to 1.7.4-5 and seem to be running OK.
This looks like https://github.com/vgough/encfs/issues/214 which has been fixed in EncFS v1.9.2, released two days ago.
Hello, thanks @Jakob for pointing out the upstream issue. Is there any plan to backport the fix into Debian stretch? The issue is quite annoying and downgrading or using the package from sid/buster feels uncomfortable. Upstream issue 214 [1] is marked as duplicate of 348. There [2] you can find the link to a fix [3]. That specific commit is not part of the 1.9.2 release, but if you look on the compare page [4] for v1.9.1 to v1.9.2 in the official repository, then you can find the fix [5] that was actually shipped in the 1.9.2 release. So for a potential backport, you should consider [5]. Or is there any chance to get 1.9.2 into stable-proposed-updates? [1]: https://github.com/vgough/encfs/issues/214 [2]: https://github.com/vgough/encfs/issues/348#issuecomment-317240681 [3]: https://github.com/rfjakob/encfs-next/commit/990631be9f53c861d54492bba884d6b9c1a7cec5 [4]: https://github.com/vgough/encfs/compare/v1.9.1...v1.9.2 [5]: https://github.com/vgough/encfs/commit/e2f0f8e3c68604a46d8665c3b0125bb35a0d9181 Thanks! Sebastian