Tag: eCryptfs

Some days ago, playing with some kernel modules I broke the suspend subsystem of my laptop, so a hard reset is needed each time I try to suspend my laptop. Nothing too bad, but with ext4 this could lead to filesystem corruption, and in deed this happend.

Looking at the dmesg log i saw thios two errors repeated many times:

[ 761.247262] Valid eCryptfs headers not found in file header region or xattr region, inode 1179676
[ 761.247265] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Googling arround I found a possible bug with a possible solution, the bug seems to be related to 0 size files, so I tried the suggested command by my own:

find . -xdev -size 0c -exec ls ‘{}’ \; | wc -l

The command generated some permission issues, some files had root permisisons so first I had to corret this problems, with a chown:

Some days ago, playing with some kernel modules I broke the suspend subsystem of my laptop, so a hard reset is needed each time I try to suspend my laptop. Nothing too bad, but with ext4 this could lead to filesystem corruption, and in deed this happend.

Looking at the dmesg log i saw thios two errors repeated many times:

[ 761.247262] Valid eCryptfs headers not found in file header region or xattr region, inode 1179676
[ 761.247265] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Googling arround I found a possible bug with a possible solution, the bug seems to be related to 0 size files, so I tried the suggested command by my own:

find . -xdev -size 0c -exec ls ‘{}’ \; | wc -l

The command generated some permission issues, some files had root permisisons so first I had to corret this problems, with a chown:

Looking at the dmesg I found out that each time I tried to read one on these file I got an error. Searching for 0 size files leads me to more than 700 files, but the error isn’t so spread to be reconducted to 700 files.

These files have in deed 0 byte size and deleting only these files solved the issue. So don’t follow the reported soluting for bug #372014 because you will delete many files which doesn’t need to be deleted.

You don’t need to search for 0 size files but, for files which has been corrupted by ext4 and cannot be decrypted, the only way to find this files is to open them in any way. (cat or chown or anything else)