Your message dated Thu, 18 Mar 2021 15:25:12 -0700
with message-id
<CAFHYt54LqKUa=wwytoxwg5oyxgzeg1xd+ypq--vbsez7jcm...@mail.gmail.com>
and subject line Re: Bug#984716: gocryptfs: data loos upon full root file system
has caused the Debian Bug report #984716,
regarding gocryptfs: data lost when root file system is full
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
984716: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984716
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gocryptfs
Version: 1.6.1-1+b20
Severity: critical
Justification: causes serious data loss
Dear Maintainer,
I'm using a gocryptfs container. Both the save location and mount point are on
partitions other then "/" that where not full. Whilst installing packages with
apt the root file system got overfilled. After fixing that situation by
deleting log files and rebooting (reboot was necessary as for unknown reasons
the root file system still reported to be full) I noticed that the content of
some of the directories in the mounted gocryptfs were empty.
Running gocryptfs -fsck (...) gave:
Using config file at custom location (...)
Password:
Decrypting master key
OpenDir "": invalid entry "._sync_7629b36e80e0.db-wal": illegal base64 data at
input byte 0
OpenDir "": invalid entry "._sync_7629b36e80e0.db-shm": illegal base64 data at
input byte 0
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-wal"
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-shm"
OpenDir "": invalid entry "._sync_7629b36e80e0.db": illegal base64 data at
input byte 0
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db"
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck summary: 10 corrupt files
Looking into the encrypted directory after that showed that the encrypted data
was missing. This wasn't verified before running "gocryptfs -fsck".
Interestingly the directories that lost their content are alphabetically last
if sorted by encrypted directory name.
Both filesystems, the root filesystem and the filesystem that hosts the
gocryptfs ecrypted directory are ext4.
I can not be sure that this is caused by gocryptfs and not by some underlying
filesystem problem, but I think it warents checking if gocryptfs can be
dammaged by a filled root file system. For example by not being able to use
/tmp?
Best
Matthias
-- System Information:
Debian Release: 10.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gocryptfs depends on:
ii libc6 2.28-10
ii libfuse2 2.9.9-1+deb10u1
ii libssl1.1 1.1.1d-0+deb10u5
gocryptfs recommends no packages.
gocryptfs suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Dear Matthias,
On Sun, Mar 7, 2021 at 8:39 AM Matthias Jäger <matthias_jae...@gmx.net> wrote:
>
> I can not be sure that this is caused by gocryptfs
Following the closure of this issue upstream [1] I am closing this bug
also. Please reopen if a causal relationship appears likely again.
Thanks!
Kind regards
Felix Lechner
[1] https://github.com/rfjakob/gocryptfs/issues/550#event-
--- End Message ---
