ecryptfs_writepage: Error

Linux schlepper 3.0.0-12-generic #19-Ubuntu SMP Fri Sep 23 21:23:39 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

tankdriver (stoneraider) mentioned this error message here: https://bugs.launchpad.net/ecryptfs/+bug/509180/comments/137

This is likely from the following upstream kernel commit, which was fixing an oops: http://git.kernel.org/linus/f61500e000eedc0c7a0201200a7f00ba5529c002

Michael, or tankdriver, can you tell me anymore about what you're doing when seeing this error?

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 870326

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

@Tyler Hicks

unfortunately I can currently not explicitly perform an action to reproduce to create this error at the same time, but I see this message very often in the logfile.

prehistory:
I Installed the current Ubuntu Beta on my laptop. The /home partition is untouched and i use old "encryptet home" of my user.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

hi,

i am having this problem after installing 11.10 amd64
after reinstalling 11.10 and re-using existing encrypted home partition i find these entries on my /var/log/kern.log

Oct 9 20:58:06 mypc kernel: [ 2406.561924] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000001c])
Oct 9 20:58:36 mypc kernel: [ 2436.563442] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
Oct 9 20:58:36 mypc kernel: [ 2436.563447] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000001d])
Oct 9 20:58:36 mypc kernel: [ 2436.563482] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
Oct 9 20:58:36 mypc kernel: [ 2436.563484] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000001d])
Oct 9 20:58:36 mypc kernel: [ 2436.563519] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
Oct 9 20:58:36 mypc kernel: [ 2436.563520] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000001d])
Oct 9 20:59:06 mypc kernel: [ 2466.566910] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
Oct 9 20:59:06 mypc kernel: [ 2466.566915] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000001e])
Oct 9 20:59:06 mypc kernel: [ 2466.566950] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]

could you tell me what info you require to investigate this?
this problem is really worrying since it may imply that i could have my private data corrupted.

uname -r
3.0.0-11-generic

@Nicholas

There is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

hi,

i have upgrade the kernel
uname -r
3.0.0-12-generic

and i still receive same errors
kernel: [ 5423.240071] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000008d])
kernel: [ 5453.519194] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]

what else would you like to try?

thanks,

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the release candidate kernel versus the daily build. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

I can confirm the same. I recently experienced a flood of thousands of such ecryptfs dmesg errors, so many that I was alerted to the issue by errors regarding zero disk space remaining.

After reading up on Bug #372014, I resolved (hopefully) the issue by deleting all ecryptfs-encrypted files of zero length:

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

will output the number of such files. I then proceeded to remove the listed files.

current version of encryption would need something like

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

could you also confirm that removing the zero size files from the encryption folder has solved this problem?

thanks,

find /home/.ecryptfs/$USER/.Private/ -size 0c -exec ls '{}' \; | wc -l
find: "/home/.ecryptfs/michael/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWaayGbRiJnCGUT.cGbKYcjW1tkyqmYP2Ls7mgjb5WeUuQCBBFHIIaItYk--/ECRYPTFS_FNEK_ENCRYPTED.FWaayGbRiJnCGUT.cGbKYcjW1tkyqmYP2Ls7BV8DM17FbQ9PayEKgxv6Uk--": Keine Berechtigung
0

@Nicolas: Yes, actually $HOME/.Private is simply simlinked to /home/.ecryptfs/$USER/.Private - so the result is the same.

After deleting the 24 found zero-length encrypted files, I've not experienced the issue again. No more dmesg errors. This is after several reboots also.

Clearly this is neither the desired solution, nor a clean one, but simply a workaround. Hopefully the root cause can be determined and fixed.

thnaks tekstr1der

i will remove my files 300+ and post back

Update: I experienced this bug again today. I had a pretty heavy workload with virtual machines and rdp sessions active. Once again, my dmesg log was flooded to the point where I was alerted to "0 disk space remaining" error, and system was unresponsive.

This required an REISUB since all my tty's were flooded with the error and I was unable to shutdown more gracefully.

I've reverted to the stock natty kernel:

$ uname -r
2.6.38-11-generic

temporarily in hopes that that it is not affected. What really bothers me about this bug is that I'd been running the oneiric kernel 3.0.0-11.18 (based on upstream 3.0.4) for some time now without issue. The ecryptfs corruption happened suddenly and in the same timeframe as other users on here and on the ubuntu forums.

See:
http://ubuntuforums.org/showthread.php?t=1857352

Of course the forum closed before we could discuss further!

Nope...happened again with the default natty kernel 2.6.38-11.50. Looks like the corruption is getting more severe. I'll post a log when able.

These messages occur here a fresh installation as well: I just did a clean install of Oneiric with the current stable kernel 3.0.0-12-generic and also got exactly the same messages as you. However the command mentioned in #38 yields no zero-length files in my folder.

I had a spate of such messages on a fresh oneiric installation. There are no zero-length files (although there are some zero-length directories, this being a btrfs file system).

I also received this error when I installed amd64 for the first time on my computer. I was having trouble getting the install to complete (kept crashing), so i played around with my bios setting and turned off the "High Performance Event Timer" (HPET). Installed fine, but then I started receiving these errors, so I switched it back on and set it to 64-bit (was previously 32-bit). May be just a co-incidence, or the fact that I rebooted the system so many times, but the problem has gone and that was the only real change I have made. Not sure if that helps.....

sorry guys - ignore my last post. Problem has now re-appeared. Would be very interested in a fix for this. Thanks.

I think this bug is causing data corruption.

I was in the process of moving my files off the encrypted partition to an unencrypted partition:

chris@chris:~$ sudo mv dotfiles /home/chris2/
[sudo] password for chris:
mv: cannot open `dotfiles/.du.txt.swp' for reading: Input/output error
mv: cannot open `dotfiles/.du.txt.swx' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.8SWB6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.YSGG6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.R2UH6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.TEQG6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.XJ1D6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.PASY5U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.HNKY5U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.6VJI6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.IWN95U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.N8IH6U' for reading: Input/output error
mv: cannot open `dotfiles/.gnome2/nautilus-sendto/pidgin_buddies_online.RPZ15U' for reading: Input/output error
mv: cannot open `dotfiles/.recently-used.xbel.MC8H6U' for reading: Input/output error
chris@chris:~$

the errors are all about zero-length files that it can't read. Because of the errors, the original folder wasn't deleted. I then ran a 'diff -r' and found that in addition to the zero-length files that didn't get copied, some files with real content were copied wrongly. Over 15,000 files were copied. Only 6 were copied incorrectly, and they were all in the same folder. All 6 files in that folder were copied incorrectly:

chris@chris:~/dotfiles/.keychain$ ls -l /home/chris/dotfiles/.keychain
total 48
-rw------- 1 chris chris 80 2010-09-02 18:32 chris-laptop-csh
-rw------- 1 chris chris 58 2010-09-02 18:32 chris-laptop-csh-gpg
-rw------- 1 chris chris 136 2010-09-02 18:32 chris-laptop-fish
-rw------- 1 chris chris 87 2010-09-02 18:32 chris-laptop-fish-gpg
-rw------- 1 chris chris 110 2010-09-02 18:32 chris-laptop-sh
-rw------- 1 chris chris 74 2010-09-02 18:32 chris-laptop-sh-gpg
chris@chris:~/dotfiles/.keychain$ ls -l /home/chris2/dotfiles/.keychain
total 24
-rw------- 1 chris chris 80 2010-09-02 18:32 chris-laptop-csh
-rw------- 1 chris chris 58 2010-09-02 18:32 chris-laptop-csh-gpg
-rw------- 1 chris chris 136 2010-09-02 18:32 chris-laptop-fish
-rw------- 1 chris chris 87 2010-09-02 18:32 chris-laptop-fish-gpg
-rw------- 1 chris chris 110 2010-09-02 18:32 chris-laptop-sh
-rw------- 1 chris chris 74 2010-09-02 18:32 chris-laptop-sh-gpg
chris@chris:~/dotfiles/.keychain$ for i in *; do cmp /home/chris{,2}/dotfiles/.keychain/$i; done
/home/chris/dotfiles/.keychain/chris-...

Clean install of Xubuntu Oneiric Ocelot with new custom partition table:

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 16G 2.9G 12G 20% /
/dev/sda4 221G 304M 210G 1% /home
/home/fakename/.Private
                                221G 304M 210G 1% /home/fakename
/dev/sda2 11G 157M 9.5G 2% /media/fakenumbersandletters

swap is 256 MB

All I did so far was run updates and reboot once.

Can someone explain to dummies what this error means?
Is my filesystem corrupt?
What is the appropriate action to take now? Reinstall?
Try different filesystem? Install without home encryption?

If you read the post above you will get the info..

Rickard, can you be more specific? Which post above has any useful information in it? I'd also like to know if this bug is causing filesystem corruption or not, and what to do about it.

I've waited for a week since my last update on this bug to ensure that I have resolved the situation.

I was starting to experience serious corruption after repeatedly deleting zero-length files per my comment #37. They kept cropping up with each new reboot. If I spent more than an hour or so in Ubuntu my .xsession-errors file would grow so large I'd run out of disk space!

I also continued to experience this bug with various kernels including then-current natty (2.6.38-11) and then-current oneiric (3.0.0-12). I could not get the mainline 3.0.6 kernel to boot without oops so could not test that.

Anyway, I ended up deciding to stay out of my ubuntu partition, considering every boot resulted in new corruption (e.g. gnome-terminal profile settings gone, wireless secrets were forgotten even though they remained listed in seahorse).

Steps I took to fix this:

1) Booted into Arch linux (separate partition) and mounted the ecryptfs partition (my ubuntu ~/) to a new mountpoint. Info on how to do this can be found in the ubuntu wiki for ecryptfs here:
https://help.ubuntu.com/community/EncryptedPrivateDirectory

2) Tar/copy all files/folders from my old ecryptfs-encrypted /home to a temporary unencrypted folder. Best to use tar for this so you get all the dot-files.

3) Deleted all files/folders from the encrypted directory. This also deletes all the encrypted copies under /home/.cryptfs/$USER/.Private which is the point of this exercise.

4) Un-tar/copy all files/folders back from unencrypted temporary folder to the ecryptfs folder, thus forcing them all to be re-encrypted.

I've not had the slightest hint of this issue reappear (about 5 days now). I've since upgraded the kernel to 3.0.0-13.21 and continue to be trouble-free. Hope this works for others too.

Thanks tekstr1der.

I think I'll leave my files unencrypted until this is fixed. Thanks for
confirming that this is really causing corruption and isn't just an issue
with zero length files.

This bug needs to be given some attention, and marked as being important,
since it's causing file corruption, and is in a package that is installed by
default.

I tried finding the mailing list for the upstream project, but it seems to
be dead.

https://lists.sourceforge.net/lists/listinfo/ecryptfs-users tells me "No
such list *ecryptfs-users*" and
http://dir.gmane.org/gmane.comp.file-systems.ecryptfs gives me errors too.

On 2011-10-21 00:00:22, Chris Moore wrote:
> This bug needs to be given some attention, and marked as being important,
> since it's causing file corruption, and is in a package that is installed by
> default.

I'm currently looking into the problem. Sorry, I should have done a
better job at updating the bug status.

>
> I tried finding the mailing list for the upstream project, but it seems to
> be dead.

I'm the upstream maintainer and this is the upstream bug tracker, so no
need to go to the list at this point.

BTW, we recently moved our mailing list and had trouble getting gmane
archiving set up so the uptake on the new list has been slow so far.

http://vger.kernel.org/vger-lists.html#ecryptfs

Don't forget to update the link
in /usr/share/doc/ecryptfs-utils/ecryptfs-faq.html where it says:

Send a message to the <a
href="http://lists.sourceforge.net/lists/listinfo/ecryptfs-users
">ecryptfs-users</a>
mailing list.

On Thu, Oct 20, 2011 at 5:16 PM, Tyler Hicks <email address hidden> wrote:

> BTW, we recently moved our mailing list and had trouble getting gmane
> archiving set up so the uptake on the new list has been slow so far.
>

Interestingly deleting the user (including files) with Users Administration Tool, rebooting and then recreating the same user (enabling home encryption again of course) with the exact same id fixes the problem.

It's hard to say if something 'fixes the problem'. I've gone over 24 hours
of working on lots of files after rebooting without seeing the problem only
to have it come back later.

Has anyone affected discovered a reliable way to trigger this bug? I'm not able to reproduce it myself, which makes it difficult for me to begin fixing the problem. If you can't exactly pinpoint what you were doing when you saw these errors, your best guesses could be helpful.

I found out that when i've used software center the error came up.. so i hade to reboot my system and when i got back in to the system again it ran fine.. but directly when i open software center the errors came back.. and my system started to act funny.. couldn't reboot the system via the reboot/shutdown button or either type reboot/halt in the console.. i've had to push the reset button on my computer case..

>If you can't exactly pinpoint what you were doing when you saw these errors, your best guesses could be helpful.

1
Fresh install of Xubuntu 11.10 64bit with completely new partitions (all ext4).
2
Swap 256MB, single user with encrypt home option.
3
After installation was complete and I logged in the first thing I did was play around with settings manager (mouse, theme, fonts, etc...) and use Firefox. Then came system updates and reboot. Unfortunately I do not remember then exactly I decided to check dmesg in terminal.

it seems to be the Software Center (SC) that triggers this behavior.

i have run the following snipet multiple times - checking to see if it was related to size of files would cause it.
for i in {1..100} ; do dd if=/dev/urandom of=file_n_$i.dd bs=${i}M count=1 ; done

nothing happens

but following Richard Perdal's comment, i left the above snipet running and opened SC - and the errors started again.

my installation is 11.10 amd64 using Intel i5 with nvidia gpu
my partitions:
<root> is btrfs
<home> is EXT4

would like me to gather further info?

Thanks for the tips Rickard, klerfayt, and Nicolas - Software Center is triggering it for me. No further info needed.

I have a zero-byte file in my encrypted home which produces an error in the
log every time I try to read it:

chris@chris:~/bad$ tail -n 0 -f /var/log/kern.log &
[2] 13767
chris@chris:~/bad$ ls -l 1
-r--r--r-- 1 chris chris 0 2011-09-19 22:23 1
chris@chris:~/bad$ cat 1
cat: 1: Input/output errorOct 21 10:52:55 chris kernel: [90246.950759]
Valid eCryptfs headers not found in file header region or xattr region
Oct 21 10:52:55 chris kernel: [90246.950764] 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

chris@chris:~/bad$ md5sum 1
md5sum: 1: Input/output error
chris@chris:~/bad$ Oct 21 10:53:08 chris kernel: [90260.668451] Valid
eCryptfs headers not found in file header region or xattr region
Oct 21 10:53:08 chris kernel: [90260.668459] 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 there's anything I can run on this file to help, I can do.

Chris.

I've identified what software-center (actually, it is the python bsddb module) is doing to trigger this. A simple file 'open() -> mmap() -> close() -> modify the mapping' will hit this bug.

332ab16f is the upstream commit that likely introduced this regression. It was an attempt to fix a problem where lower files could remain open for the lifetime of an eCryptfs mount, but this is an ugly regression. I'm going to try to come up with a clean, simple fix but if that's not possible, reverting that commit would probably be the next best thing.

Since this is a critical bug, I wanted to give a quick update. I've wrote a patch which fixes this issue but it is triggering a new lockdep warning. I think it is a false positive, but I've got more investigation to do before I'm sure of that.

Hello!

how did you manage to fix the bug?
please inform me so i can help out with this..

//Rickard.

On 10/25/2011 05:57 PM, Tyler Hicks wrote:
> Since this is a critical bug, I wanted to give a quick update. I've
> wrote a patch which fixes this issue but it is triggering a new lockdep
> warning. I think it is a false positive, but I've got more investigation
> to do before I'm sure of that.
>

Have this problem too, and I think it makes my system unstable.
How can I fix it?

I'm hitting this exact same issue. I initially noticed this in software center, when clicking 'install' there was no progress, it returned immediately.

I then tried to backup the ~/.thunderbird directory and got permission errors, noticed that some files were owned by root. I chowned them and then got INPUT/OUTPUT errors.

The funny thing is, if I login to my gnome-shell or gnome-fallback sessions everything works perfectly. I only seem to be affected if I run unity or unity-2d.

I was finally able to track down the lockdep issue I mentioned in comment #66. It was a bug with how the VFS was using lockdep. Since this was a lockdep false positive, it allows for the fix to be very clean and simple. The patch I'm attaching is against 3.2-rc1.

I've built an Oneiric test kernel, based upon 3.0.0-12.20, which contains this fix and a fix for bug #813146. Here are the links:
http://people.canonical.com/~tyhicks/ecryptfs/linux-headers-3.0.0-12-generic_3.0.0-12.20+ecryptfs1_amd64.deb
http://people.canonical.com/~tyhicks/ecryptfs/linux-image-3.0.0-12-generic_3.0.0-12.20+ecryptfs1_amd64.deb

I encountered this bug with a clean install of 11.10 on a Lenovo X1 and could see the problem also after starting the software center. I'm now using the kernel from #70 and it seems to fix the problem for me. At least there are no more messages.

Is the patch expected to make its way upstream and into the official Ubuntu kernel? How long is that process usually take?

Will the patch in comment #70 be included in the 3.0.9 rebase kernel update proposed in bug# 890952 :Oneiric update to 3.0.9 stable release?

It's been a month since I've triggered this problem, but I mistakingly double-clicked a .deb file, which launched Software Center. Later on, I got the usual slew of errors and full disk message and now can no longer boot into the Ubuntu partition. I will need to follow the steps I outlined in comment #53 to remedy this again. I will start using the patched kernel immediately.

I realize this is marked critical, and it's certainly a real show-stopper bug. I just want to be sure the fix has been verified and will definitely be included in kernel updates for Oneiric going forward.

@Tyler Hiks: Can you confirm this?

Specifically, the latest test version of the proposed Oneiric kernel:

linux - 3.0.0-14.23~pre201111190400
https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages

was built earlier today and does not appear to contain the fix in comment# 70. This is disconcerting for those of us regularly affected by this data-destructive bug.

Released in 3.2-rc3:

http://git.kernel.org/linus/32001d6fe9ac6b0423e674a3093aa56740849f3b

Submitted to Ubuntu kernel-team list:

https://lists.ubuntu.com/archives/kernel-team/2011-November/017949.html

Status changed to 'Confirmed' because the bug affects multiple users.

Will this patch included in a kernel available in oneiric-updates or in oneiric-backports?

@cheoppy: The patch is included in the latest pre-proposed kernel build for Oneiric: linux - 3.0.0-15.24~pre201112060400 ( started 7hrs ago, still building currently).

It will eventually make it's way to proposed, followed by the stable release to the updates repository. No need for backports.

@tekstr1der: How long usually does that cycle take?

Would it be sensible to download a recently built kernel from the ppa with this patch included to avoid possible data corruption? And when 3.0.0-15.24 arrives to oneiric-updates I would switch to that.

Great Idea

+1

On 06/12/11 22:59, cheoppy wrote:
> @tekstr1der: How long usually does that cycle take?
>
> Would it be sensible to download a recently built kernel from the ppa
> with this patch included to avoid possible data corruption? And when
> 3.0.0-15.24 arrives to oneiric-updates I would switch to that.
>

@cheoppy: Yes. Exactly what you described is what I would do if affected by this bug. And I am, so I did.

Hopefully one of the builds with the fix makes it through SRU soon. I hate to wonder how many people are affected by this, but have no idea the cause or solution.

This bug is awaiting verification that the kernel for Oneiric in -proposed solves the problem (3.0.0-15.24). Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-oneiric' to 'verification-done-oneiric'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

My testing uncovered no regressions.

Wrong bug; apologies - forget about #83.

Tested and verified this fix through the various pre-proposed kernels since it was committed, and now using the 3.0.0-15.24 kernel in Proposed.

Never have had the issue crop up again. Thanks!

I can confirm it has been fixed with the 3.0.0-15.24 kernel.

This bug was fixed in the package linux - 3.0.0-15.25

---------------
linux (3.0.0-15.25) oneiric-proposed; urgency=low

  [Brad Figg]

  * Release Tracking Bug
    - LP: #910894

  [ Upstream Kernel Changes ]

  * Revert "clockevents: Set noop handler in clockevents_exchange_device()"
    - LP: #904569

linux (3.0.0-15.24) oneiric-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #903188

  [ Alex Bligh ]

  * (config) Change Xen paravirt drivers to be built-in
    - LP: #886521

  [ Chase Douglas ]

  * Revert "SAUCE: HID: hid-ntrig: add support for 1b96:0006 model"
    - LP: #724831
  * Revert "SAUCE: hid: ntrig: Remove unused device ids"
    - LP: #724831

  [ Seth Forshee ]

  * SAUCE: dell-wmi: Demote unknown WMI event message to pr_debug
    - LP: #581312

  [ Upstream Kernel Changes ]

  * Revert "leds: save the delay values after a successful call to
    blink_set()"
    - LP: #893741
  * xfs: Fix possible memory corruption in xfs_readlink, CVE-2011-4077
    - LP: #887298
    - CVE-2011-4077
  * drm/i915: fix IVB cursor support
    - LP: #893222
  * drm/i915: always set FDI composite sync bit
    - LP: #893222
  * jbd/jbd2: validate sb->s_first in journal_get_superblock()
    - LP: #893148
    - CVE-2011-4132
  * ALSA: hda - Don't add elements of other codecs to vmaster slave
    - LP: #893741
  * virtio-pci: fix use after free
    - LP: #893741
  * ASoC: Don't use wm8994->control_data in wm8994_readable_register()
    - LP: #893741
  * sh: Fix cached/uncaced address calculation in 29bit mode
    - LP: #893741
  * drm/i915: Fix object refcount leak on mmappable size limit error path.
    - LP: #893741
  * drm/nouveau: initialize chan->fence.lock before use
    - LP: #893741
  * drm/radeon/kms: make an aux failure debug only
    - LP: #893741
  * ALSA: usb-audio - Check the dB-range validity in the later read, too
    - LP: #893741
  * ALSA: usb-audio - Fix the missing volume quirks at delayed init
    - LP: #893741
  * KEYS: Fix a NULL pointer deref in the user-defined key type
    - LP: #893741
  * hfs: add sanity check for file name length
    - LP: #893741
  * drm/radeon: add some missing FireMV pci ids
    - LP: #893741
  * sfi: table irq 0xFF means 'no interrupt'
    - LP: #893741
  * x86, mrst: use a temporary variable for SFI irq
    - LP: #893741
  * b43: refuse to load unsupported firmware
    - LP: #893741
  * md/raid5: abort any pending parity operations when array fails.
    - LP: #893741
  * mfd: Fix twl4030 dependencies for audio codec
    - LP: #893741
  * xen:pvhvm: enable PVHVM VCPU placement when using more than 32 CPUs.
    - LP: #893741
  * xen-gntalloc: integer overflow in gntalloc_ioctl_alloc()
    - LP: #893741
  * xen-gntalloc: signedness bug in add_grefs()
    - LP: #893741
  * powerpc/ps3: Fix lost SMP IPIs
    - LP: #893741
  * powerpc: Copy down exception vectors after feature fixups
    - LP: #893741
  * backing-dev: ensure wakeup_timer is deleted
    - LP: #893741
  * block: Always check length of all iov entries in blk_rq_map_user_iov()
    - LP: #893741
  * Linux 3.0.10
    - LP: #893741
  * drm/i915: add multi-threaded forcewake support
    - LP: #891270
  * (pre-sta...

this happends every hour or so , ending up stopping me from doing anything , (cannot unlock desktop or run an application ) works for another hour or two after reboot.

kernel 3.0.0.16

At least for me, the problem still persists on Lubuntu 12.04, Kernel "3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:54:40 UTC 2012 i686 athlon i386 GNU/Linux", all updates installed up to now. In the "dmesg" log, i got the error messages below. However, my disk is certainly not full (> 100 GB left on "/", no other partitions mounted except for swap). No other error except for an ACPI error can be found in the log.

Relevant Dmesg log part:
---------------
[ 3571.816762] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.816781] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000000])
[ 3571.817002] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.817011] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000000])
[ 3571.817232] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.817240] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000000])
[ 3571.817463] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.817471] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000000])
[ 3571.817751] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.817761] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000001])
[ 3571.817978] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.817987] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000001])
[ 3571.818205] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3571.818214] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000001])
[ 3576.816516] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.816535] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000002])
[ 3576.816761] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.816770] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000002])
[ 3576.816990] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.816999] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000000d])
[ 3576.817284] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.817293] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000003])
[ 3576.817512] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.817520] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000003])
[ 3576.817739] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3576.817748] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000011])
[ 3581.816755] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3581.816775] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000004])
[ 3581.816998] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5]
[ 3581.817007] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000013])
[ 3581.817308] ecryptfs_encrypt_page: Error attempting to write lower ...

Hi Ruedi - Unfortunately, this bug was reintroduced recently. The good news is that it has been fixed upstream and updated Ubuntu kernels are on their way. You can find more information, as well as links to test kernels, in bug 1047261.

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".