zero byte files in dmesg

I believe this is a problem that Dustin has ran into before. It is due to ext4 and zero-length files (http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/).

When a file is created in an eCryptfs mount, we go ahead and create the file in the lower filesystem and write out the eCryptfs metadata (encrypted file key, decrypted file size, etc.). Anytime that a file open is performed, we expect that metadata to be present or we consider it a non-eCryptfs file and ignore it by returning -EIO. You are seeing the warning message from an open on a file that doesn't have the proper eCryptfs metadata.

We may be able to let the zero-length files slide and generate and write the header information on the first file write. The problem with this is that it may break the way that users expect ecryptfs_passthrough to work. You can touch a file in the lower filesystem (creating a zero length file) and then any subsequent writes from the eCryptfs mount point will be passed through instead of encrypting the data.

That may just be a little trick that I do for testing and not something that any users actually do. I need to think about that a little more.

What errors are you specifically seeing?

:-Dustin

The same:

$ dmesg | tail
[32955.246231] Valid eCryptfs headers not found in file header region or xattr region
[32955.246248] 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
[33019.249402] Valid eCryptfs headers not found in file header region or xattr region
[33019.249418] 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
[33573.256403] Valid eCryptfs headers not found in file header region or xattr region
[33573.256420] 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
[33651.229472] Valid eCryptfs headers not found in file header region or xattr region
[33651.229484] 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
[33713.245151] Valid eCryptfs headers not found in file header region or xattr region
[33713.245163] 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

As far as zero byte files goes, I found the following:

$ mount | grep crypt
/home/tobuntu/.Private on /home/toobuntu type ecryptfs (ecryptfs_sig=[sanitized],ecryptfs_fnek_sig=[sanitized],ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

$ find /home/toobuntu/ -xdev -size 0c -exec ls '{}' \; | wc -l
233

Hmm, here are some examples:
$ ls -lAhS | tail -n 5
-rw-r----- 1 toobuntu toobuntu 0 Jun 24 09:12 .gksu.lock
dr-x------ 3 toobuntu toobuntu 0 Jun 24 09:11 .gvfs
-rw-r--r-x 1 toobuntu toobuntu 0 Mar 1 13:56 .nofinger
-rw-r--r-- 1 toobuntu toobuntu 0 Mar 30 07:06 .screenrc
-rw-r--r-- 1 toobuntu toobuntu 0 Mar 1 00:35 .sudo_as_admin_successful

Anyone here running karmic?

I am, on with an encrypted home on top of ext4 and my 'dmesg | grep ecryptfs' is clean. jdstrand said the same thing about his encrypted-private on karmic.

I think tyhicks has cleaned these up in the upstream kernel. Jaunty is affected, though, I can confirm that.

:-Dustin

Marking confirmed in Jaunty, fixed in Karmic.

:-Dustin

I'm on karmic with installer-encrypted home dir, and I'm suffering hardlocks / total freeze where the last kernel message is always the above "returning -EIO" message.

dmesg | grep ecryptfs gives this:
[ 2343.922098] ecryptfs_read_lower: octets_read = [-4]; expected [4096]
[ 2343.922111] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-22]

Started seeing this messages yesterday, I believe I might have begun in my machine since 2.6.31-14-generic . I am using jaunty with karmic's kernel . Tried updating ecryptfs-utils and associated library to karmic without sucess.

I am losing firefox sessions as it fails to record it (using sessionmanager).

ext4 filesystem, btw, with full home encrypted (I used netinst with jaunty in order to install ubuntu-netbook). It used to work :(.

I am seeing

[20708.790099] ecryptfs_read_lower: octets_read = [-4]; expected [4096]
[20708.790104] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-22]

But not the messages reported in the bug above.

If you are concerned about these different messages, please open a new bug.

:-Dustin

I too am getting this...

Oct 26 17:55:28 hactar kernel: [ 5849.850460] Valid eCryptfs headers not found in file header region or xattr region
Oct 26 17:55:28 hactar kernel: [ 5849.850465] 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
Oct 26 17:55:31 hactar kernel: [ 5853.094723] Valid eCryptfs headers not found in file header region or xattr region
Oct 26 17:55:31 hactar kernel: [ 5853.094728] 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

Same here, running on Karmic:

[ 557.770730] Valid eCryptfs headers not found in file header region or xattr region
[ 557.770736] 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

same here also on Karmic:

[ 616.544860] Valid eCryptfs headers not found in file header region or xattr region
[ 616.544868] 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

How is this fixed in Karmic? I still have this issue.

Nothing mentioned about this bug in http://changelogs.ubuntu.com/changelogs/pool/main/e/ecryptfs-utils/ecryptfs-utils_81-0ubuntu3/changelog

No package available from karmic-updates.

still have the issue as well

When error fixed!?
Linux compixxx 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
Dec 25 17:41:56 comp-1328 kernel: [ 9828.170706] Valid eCryptfs headers not found in file header region or xattr region
Dec 25 17:41:56 comp-1328 kernel: [ 9828.170710] 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
Nautilus + eCryptfs = crashed my computer

Hey, guys with no errors, see "dmesg | grep eCryptfs" not ecryptfs.
I have karmic with 2.6.31-17-generic #54-Ubuntu... and my dmesg is full of
"...
[ 1842.564107] Valid eCryptfs headers not found in file header region or xattr region
[ 1842.564116] 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
[ 1842.564309] Valid eCryptfs headers not found in file header region or xattr region
[ 1842.564315] 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
..."

ecryptfsd -V
ecryptfsd (ecryptfs-utils) 81

But my system works fine and I have no any troubles with crashes or file accessing. Is my encryption actually works? (-:

I have these problems as well and it's killing my performance on my netbook.

Jan 4 19:03:17 booffalo kernel: [ 3620.937938] Valid eCryptfs headers not found in file header region or xattr region
Jan 4 19:03:17 booffalo kernel: [ 3620.937949] 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
joey@booffalo:~$ uname -a
Linux booffalo 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux

The problem turned out to be 2 zero-byte files in my .Private directory. I verified via fuser that they weren't in use and deleted them. Thanks to Dustin for the help.

I worked with Joey on IRC to track this down.

This situation occurs when 0-byte files are created in the underlying filesystem.

It's not entirely clear to me under what circumstances this can happen. Previously, this was caused by EXT4 errors. I haven't seen those in practice now in over 6 months. Perhaps there's something else wrong.

In any case, you can solve this for yourself by making sure that the 0-byte files are not in use, and then deleting them.

Something like this might help:

for i in find $(mount | grep " on $HOME type ecryptfs" | awk '{print $1}') -size 0c; do
  if ! fuser -v $i; then
    rm -f $i
  fi
done

Then clear your dmesg with:
 sudo dmesg -c

And see if they come back...

@Dustin:

jake@jTop:~$ mount | grep ecrypt
/home/jake/.Private on /home/jake type ecryptfs (ecryptfs_sig=7813e396697f6d86,ecryptfs_fnek_sig=d39d3eb8f9f89777,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
jake@jTop:~$ find /home/jake/.Private -size 0c
find: `/home/jake/.Private': No such file or directory

Sometimes the eclipse (3.5.1) crashes as soon as I create new empty file and save it. Then I can see familiar line in dmesg:
[ 940.882640] 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

Even without using eclipse my dmesg log is also full of these.. It never happened before (3-4 weeks ago everything was all right).

Ubuntu 9.10
2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux

This is Ubuntu 9.10 here. I always install latest updates with update manager.

ecryptfsd -V
ecryptfsd (ecryptfs-utils) 81

The directory tree under mount | grep ecryptfs does not have any zero size files.

I cleared dmesg before logging in.

dmesg | grep eCrypt

[ 3537.369696] Valid eCryptfs headers not found in file header region or xattr region
[ 3537.369703] 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
[ 3922.179030] Valid eCryptfs headers not found in file header region or xattr region
[ 3922.179037] 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
[ 4033.040837] Valid eCryptfs headers not found in file header region or xattr region
[ 4033.040844] 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

I am still looking for the culprit for the freezes and frequent need for manual ext4 fs check on my notebook that has an SSD.

I found the file that caused these messages.

cat ~/.cache/desktop-couch/desktop-couchdb.pid
cat: desktop-couchdb.pid: Input/output error

This was the second time that this file got corrupted. It is a coincidence?
It cause couchdb not to start. I removed the pid file.

From an end-user point of view it would help if a more verbose log message would tell us which file is causing the problem, if it is de-cryptable.

Ok.. this sounds horrible, is there any solution in sight?

$ find . -xdev -size 0c -exec ls '{}' \; | wc -l
2387

\o/

(karmic, encrypted home, ssd, lots of hangs -> lots of unfriendly power-offs), ThinkPad X200

I'd recommend avoiding the workaround which deletes "unused" zero-byte files. It disrupted a lot of lock files, causing Evolution to be unable to write to any IMAP folders on my machine as well as, for example, causing NetBeans to require me to re-accept its license agreement, etc.

I'm now waiting for various next shoes to drop. This is in a Karmic VirtualBox VM with a current kernel:
Linux hostname 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux

I'm seeing these same messages and freezes on Lucid Beta 1 Netbook Edition.

I keep having this message, everything started two weeks ago, suddenly. I'm using Ubuntu 9.10.
I have crypted home partition since Ubuntu 9.04, one year.
After a while of this totally unuseful log, my system freezes completely.

I think I will remove ecryptfs, after decrypting my home directory.

Please, please, please.. PRINT the name of the file causing the problem in the log!!! I don't think it should be too difficult..

Now also occurs here, on karmic, uname -a
Linux xxxxxxxxxx 2.6.31-20-generic-pae #58-Ubuntu SMP Fri Mar 12 06:25:51 UTC 2010 i686 GNU/Linux

There is no apparent performance or data loss.

I am monitoring the situation using this command to find which 0-size files were recently modified (assuming /home/yyyyyyyyy/ is the encrypted directory, find out with mount | grep crypt):

find /home/yyyyyyyyy/ -xdev -size 0c -printf '%TY%Tm%Td.%TH:%Tm %p\n' | sort > z.txt

then I test one by one for being in use, (fuser -v filename), delete, clear the kernel ring buffer (sudo dmesg -c) and see if they come back. Will report any news.

I'm seeing this on lucid now.
[44984.410245] Valid eCryptfs headers not found in file header region or xattr region
[44984.410258] 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

Scott-

What's the output of:
find $HOME/.Private -xdev -size 0c -exec ls '{}' \; | wc -l

Basically, do you have any 0-length files? If so, it's probably the ext4 0-byte file bug. Clean those up, and see if the errors in dmesg go away.

Hi Dustin,

I have the same problem on kubuntu karmic 9.10 x86 64 and with your command. here are my output:

find $HOME/.Private -xdev -size 0c -exec ls '{}' \; | wc -l
0

I see that some 0 byte files are in my folder, i will try to delete it and see if stop the warn.

Thanks

I hope that nothing are done because when i deleted one of the 0 byte file, all .private folder are gone and can't be restored.

Any opinion welcome

The warn haven't stopped

2010-04-29 22:41:55 xxxx kernel [511407.278314] Valid eCryptfs headers not found in file header region or xattr region
2010-04-29 22:41:55 xxxx kernel [511407.278318] 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

And it was after delete the 0 byte and the folder

Linux xxxx 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:27 UTC 2010 x86_64 GNU/Linux

Amondo, Curtis, what does that mean ?

Steffen

Problem remains in Lucid* -- and is in fact much more frequent now, practically filling the dmesg logs to the point where they're no longer useful. Tried the command mentioned above, ie:

  find $HOME/.Private -xdev -size 0c -exec ls '{}' \; | wc -l

Returned 0.

Errors are same as above:
...snip...
[35503.313160] 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
[35803.356768] Valid eCryptfs headers not found in file header region or xattr region
[35803.356779] 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
[36103.351551] Valid eCryptfs headers not found in file header region or xattr region
[36103.351562] 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
[36403.328506] Valid eCryptfs headers not found in file header region or xattr region
[36403.328518] 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
[36703.315417] Valid eCryptfs headers not found in file header region or xattr region
[36703.315428] 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
...snip...

Hundreds of these messages over the course of a few hours. I'm really surprised this problem (which first started in Karmic, for my system at least) managed to make it into Lucid ... admittedly this was somewhat presumptuous of me, but I kind of thought this would be fixed before the LTS was released -- especially since the "encrypted home directory" is such a popular (and well-advertised) feature. Since upgrading to Lucid didn't fix the error, I guess I'm looking at a total reinstall (sans the ecryptfs stuff), moving my data out of my home folder and back in again, etc -- yikes.

And everything worked so well for > 1 year... only started up (for me, at least) in Q1 of 2010.

Not sure why the status was changed to invalid and the appropriate target (ecryptfs, ecryptfs-utils, etc) were replaced with "launchpad" earlier, but I'm reverting that with apologies in advance: but how exactly is this a "launchpad issue?"

*Linux 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux (Ubuntu Lucid 10.04 LTS)

I can repeatably create the error, it has become more frequent lately. I start out with ~20 GB of free space on my drive, as I run bittorrent or wine in the background free space reaches zero in 12-24 hours. After this the system cannot be shut down giving thousands of messages as such:

ecryptfs_read_lower: octets_read = [-4]; expected [4096]
ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-22]

After a hard restart the famous messages appear:

Valid eCryptfs headers not found in file header region or xattr region
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

This error keeps me losing any configuration that should have been saved in the home directory, including Firefox database, terminal settings, even gnome desktop configuration.

I think you either should warn the installing user that encrypting home directory is an experimental feature, or elevate the importance of this bug.

Ubuntu Karmic 9.10

uname -a:
Linux x64 2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 13:22:24 UTC 2009 x86_64 GNU/Linux

I've been getting this and then suddenly evince would not run until I created the folder .gnome2/evolution - which surely had previously existed. (I got the clue to do that from strace).

Until I created that folder, each time I tried to run evince I got the the ecryptfs error in my syslog.

Same here with Ubuntu 10.04. I'm going to backup all my data and reinstall without encryption... *sigh*

Same problem in Luci, the 0 length file find reports 0 0-length files.

Just a note: the find needs a trailing slash after .Private otherwise it returns 0....I had 63 found, will delete and see if that solves the problem.

Hello,

This morning after i rebooted my system, i found a new errors with ecryptfs on Lucid who wasn't before by me.

ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]

It's on a fresh install on Kubuntu Lucid 10.04 LTS LVM x86 64

Linux xxxxxxxxxxxxx 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux

Hi all,

got plenty of this in dmesg output, since filesystem runs out of space once:

[12204.181835] Valid eCryptfs headers not found in file header region or xattr region
[12204.181918] 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

Removing empty files doesn't change anything.
I use ext4 file system.

Linux xxxx 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux

I too got this issue. Running Lucid. I can submit logs and stuff, if necessary.

After I got the command line right (with the trailing slash), and therefore found the 0-byte files, I deleted the 0-byte files and it solved the problem for me.

I think this bug is related to some of my git repositories that have been corrupted :?

I've used Lucid since March with an encrypted $HOME and no problems until today. Last night, Transmission couldn't start a download because there was not enough disk space. I freed space and tried to restart the torrent, but Transmission froze and became "defunct". I didn't know how to kill that process ('kill -9' didn't work) so I rebooted and Transmission ran fine. This morning I began having problems with this bug.

I had ~1600 zero-length files in my home directory (and I deleted those related to the Transmission lockup), but only one in $HOME/.Private/ --- I deleted that one, too, but that didn't stop the eCrypt error logging.

After a little more experimenting, I found that it only occurs when Skype is running. I've deleted all the ~/.Skype/ zero-length files (locks), but every restart of Skype brings back the errors. Now I'm suspicious about the Transmission "cause", but I'm sure I didn't have the problem on Friday, since I check dmesg regularly while as part of my work.

Let me know if more information is needed. This is annoying enough to reinstall my $HOME unencrypted if not resolved relatively soon.

Thanks,
Doug

I just tried the "Windows way" of resolving this and it appears to have worked for me: I completely un-installed Skype, then reinstalled and ran it. Now I have no more problem with eCryptFS messages!

I just remove the .Skype directory, restart Skype and the messages are gone.

Thanks,
Stefan

I'm seeing this problem on Lucid 10.04.1 on a 64 bit machine with an SSD.

Prior to seeing this issue my drive was reported read-only due to encryption errors, and a reboot resulted in the error reported here.

No logs are available from the "read-only due to encryption errors" problem, because the the logs were not written...

This is not good.

Removing 0 length files solved the problem regarding the "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" messages.

I wonder why this problem arose. I suspect it may have originated prior to the reboot and subsequent automatic disk repair that occurred on my machine.

I recently noticed this error in /var/log/kern.log.1 :

Sep 2 16:55:59 simon-laptop kernel: [193370.279532] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:55:59 simon-laptop kernel: [193370.279542] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:55:59 simon-laptop kernel: [193370.279548] Error writing headers; rc = [-28]
Sep 2 16:56:03 simon-laptop kernel: [193373.918985] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:56:03 simon-laptop kernel: [193373.918995] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:56:03 simon-laptop kernel: [193373.919001] Error writing headers; rc = [-28]
Sep 2 16:56:07 simon-laptop kernel: [193378.222126] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:56:07 simon-laptop kernel: [193378.222135] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:56:07 simon-laptop kernel: [193378.222141] Error writing headers; rc = [-28]
Sep 2 16:56:22 simon-laptop kernel: [193393.160557] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28]
Sep 2 16:56:22 simon-laptop kernel: [193393.160566] ecryptfs_write_end: Error encrypting page (upper index [0x0000000000000018])
Sep 2 16:56:22 simon-laptop kernel: [193393.160686] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28]
Sep 2 16:56:22 simon-laptop kernel: [193393.160692] ecryptfs_write_end: Error encrypting page (upper index [0x0000000000000018])
Sep 2 16:56:31 simon-laptop kernel: [193402.293173] CIFS VFS: No response for cmd 50 mid 50075
Sep 2 16:56:31 simon-laptop kernel: [193402.312303] CIFS VFS: No response for cmd 50 mid 50081
Sep 2 16:56:35 simon-laptop kernel: [193405.440576] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:56:35 simon-laptop kernel: [193405.440585] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:56:35 simon-laptop kernel: [193405.440591] Error writing headers; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478510] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478519] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478525] Error writing headers; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478733] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478740] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-28]
Sep 2 16:56:40 simon-laptop kernel: [193410.478745] Error writing headers; rc = [-28]
Sep 2 16:56:42 simon-laptop kernel: [193413.325000] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28]
Sep 2 16:56:42 simon-laptop kernel: [19341...

I am getting freezes of my system and following messages happens more and more.

I have no zero length files in .Private
find $HOME/.Private -xdev -size 0c -exec ls '{}' \; | wc -l
0

[ 360.184715] 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
[ 360.302275] Valid eCryptfs headers not found in file header region or xattr region
[ 360.302279] 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
[ 360.303662] Valid eCryptfs headers not found in file header region or xattr region
[ 360.303665] 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
[ 360.306214] Valid eCryptfs headers not found in file header region or xattr region
[ 360.306216] 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
[ 360.331308] Valid eCryptfs headers not found in file header region or xattr region
[ 360.331314] 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
[ 360.332354] Valid eCryptfs headers not found in file header region or xattr region
[ 360.332357] 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
[ 360.334774] Valid eCryptfs headers not found in file header region or xattr region
[ 360.334785] 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
[ 360.336102] Valid eCryptfs headers not found in file header region or xattr region
[ 360.336105] 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
[ 360.368016] Valid eCryptfs headers not found in file header region or xattr region
[ 360.368035] 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
[ 360.381241] Valid eCryptfs headers not found in file header region or xattr region
[ 360.381662] 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
[ 360.389827] Valid eCryptfs headers not found in file header region or xattr region
[ 360.389829] 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
[ 360.887672] Valid eCryptfs headers not found in file header region or xattr region
[ 360.887676] 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
[ 360.887695] Valid eCryptfs headers not found in file header region or xattr region
[ 3...

Running Ubuntu (10.4) ext4 with ecryptfs - I was experiencing intermittent system hangs, with the following errors:

willwh@alba:~$ tail /var/log/messages
Oct 5 21:16:43 alba kernel: [ 79.277768] 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
Oct 5 21:16:43 alba kernel: [ 79.277784] 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

willwh@alba:~$ dmesg | tail
[ 193.731660] 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
[ 193.933541] Valid eCryptfs headers not found in file header region or xattr region

I removed Evolution in favour of thunderbird after installing, and after reviewing the comment from Sam Liddicott, thought this must be the issue!

Thankfully; mkdir .gnome2/evolution - I am no longer experiencing system hangs!

In ref to my last statement - looks like this is not the case. I don't boot the laptop up every day - hence the time difference between posts.

System is still hanging for me.

It also affects me...
What about installing using the alternate Ubuntu CD and choosing Cyphered LVM option?

I have this issue too; running Lucid.

I'm struggling with the concept that all zero-length files should be deleted. This sounds like ... make sure all the software you design fits the limitation of my filesystem... In my world, zero length files are fairly commonplace. And removing them screws up the systems that depend on them being there.

Does this mean ecryptfs is not ready for prime-time?

Hi,

no, it is not about the files which are 0bytes in your
mounted ecryptfs under /home/user/...,
but those encrypted-file-containers that are 0bytes
in /home/user/.Private, i.e. intheir encrypted state
where something went terribly wrong,
and which can't be decrypted anyhow.

What's really missing is a simple option to find out
*which* files are broken, so you can restore them
from your Backup. (You do backup, don't you ?)

Yours,
Steffen

-----Ursprüngliche Nachricht-----
Von: <email address hidden> im Auftrag von jeyno
Gesendet: So 11/14/2010 00:34
An: Neumann, Steffen
Betreff: [Bug 372014] Re: errors in dmesg

I have this issue too; running Lucid.

I'm struggling with the concept that all zero-length files should be
deleted. This sounds like ... make sure all the software you design
fits the limitation of my filesystem... In my world, zero length files
are fairly commonplace. And removing them screws up the systems that
depend on them being there.

Does this mean ecryptfs is not ready for prime-time?

--
errors in dmesg
https://bugs.launchpad.net/bugs/372014
You received this bug notification because you are a direct subscriber
of the bug.

Had the same problem, but it was because my disk was full. Made some space available and now it seems to work. It's a bug nevertheless because the system froze and files couldn't be written but I didn't get the "no space left" error (had to find out myself)

Having the same problem again and my disk is now NOT FULL

The same:

[12248.496719] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]
[12248.496733] Valid eCryptfs headers not found in file header region or xattr region
[12248.496736] 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
[19562.513091] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]
[19692.652094] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]

Running:

find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l
0

does return 0 - so i got no 0byte encrypted file containers in the Private folder - what else could cause this?

I can confirm this bug is in Maverick.

Deleting the .Skype dir did help for Skype, but now I also get error for Picasa.

There is a general problem with the ~/.* dirs.

Hit this problem on Natty (ext4 + ecryptfs)

Same for me on Natty (ext4 + ecryptfs)

same error here

had my $HOME full at on point and there was no error warning about it.

after deleting some files to make room.
and rebooting. i can no longer login using KDE.

i have run:

find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l

and got:

203

i also noticed that my $HOME/.ecryptfs is corrupted.
but i am able to access all my files still.

so what is the next option here? delete all these (as they are empty anyhow.
how should i proceed.

i suppose we should try to fix the BUG of no alert when running out of space here

I seem to be getting this error also.

Apr 1 20:00:34 ardbeg kernel: [ 6256.103223] 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

I can provoke it in the clear filesystem like so ...

find . -type f -exec cat {} \; > /dev/null

which results in...

cat: ./mail/misc/77735: Input/output error
cat: ./mail/misc/77811: Input/output error
cat: ./mail/misc/77829: Input/output error

I first noticed it because I use unison to sync these files. The files are zero length in the clear filesystem (and shouldn't be). I presume that are zero length in the encrypted. I certainly have zero length files in the encrypted but can't be sure they are the same, of course.

This is on 10.10. It's not a clean installation, but it is a clean user space after my initial attempts to migrate the file system to encrypted failed and broke my account.

This bug is still present for (has been for a while actually, hoped it'd get fixed but it hasn't).

Running Ubuntu 11.04 (Anything else that would be helpfull?)

added the option for 'proposed' updates on synaptics

and the problem persists.

=======================================================
[ 481.927093] Valid eCryptfs headers not found in file header region or xattr region
[ 481.927099] 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
[ 481.927312] Valid eCryptfs headers not found in file header region or xattr region
[ 481.927317] 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
=======================================================

my question is - how reliable is this method of storing my personal data encrypted?

besides keeping a backup of everything i have stored on my $HOME- is there an option to this?

thanks,

Yup, problem still exists. When it happens i have no other option than to abandon the whole virtual machine i am running and restore a older copy and use it until the problem appears again.

This persists since 2009? Seriously? I'm affected too and I'm getting dozens of these every second. I also can't see anything useful in my dmesg anymore.

Sorry for posting here but the duplicate seems to be much more comprehensive so people probably won't know what I'm talking about.

I am running into this problem with 11.10. There are literally thousands of these entries in syslog. I can't even find the valid stuff among all this extra junk.

12.04 LTS (xubuntu). amd64. Encrypted home directory. ext4. x220 thinkpad.
Getting lots of these.

[ 89.511841] Valid eCryptfs headers not found in file header region or xattr region, inode 6291493
[ 89.511852] 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

I suggest changing the log message to include the name of the file which is the source of error, otherwise the log entry is prerry useleess.

on precise the same issue

On Saucy the same issue.

The error occurs on trusty tahr as well, and for me it is definitely not a duplicate...

Karmic is past end of life by several years, and therefore I am marking this as "Won't Fix" against the Karmic task.

I am facing the same problem.

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
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
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
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

If I pass ecryptfs_passthrough option to mount, I wont see above error. But for sure this is not the solution.