Re: ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-13]

[Alexis Hafner <alexis.hafner@gmail.com>]

Hi Tyler,

I can report the same bug on a 64-bits Rhel server 6.2 machine running
the default Red Hat kernel, also with ext4 as the lower file-system :
using extended attributes fails with the same error logs. This could
indicate that the problem is not limited to the last development
kernels, but has been here a little longer.

Alexis

Le 20 déc. 2011 à 02:06, Tyler Hicks <tyhicks@canonical.com> a écrit :

> On 2011-12-19 13:26:19, Martin Steigerwald wrote:
>> Hi!
>>
>> Today I tested again whether ecryptfs would be suitable to replace encfs on my
>> laptop. But I found several problems. The blocking one is:
>
> Sorry, hopefully we can get them straightened out.
>
>>
>> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make
>> […]
>> sed: couldn't open temporary file ./sedhqlAcd: Permission denied
>> […]
>>
>> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail
>> -6
>> ls: cannot access sedhqlAcd: No such file or directory
>> ls: cannot access sedChky0a: No such file or directory
>> ls: cannot access sed1eW8Ek: No such file or directory
>> ls: cannot access sedEjR2oA: No such file or directory
>> ls: cannot access sedb4JEiI: No such file or directory
>> ls: cannot access sedy0KQnt: No such file or directory
>> -?????????  ? ?  ?            ?            ? sedChky0a
>> -?????????  ? ?  ?            ?            ? sedEjR2oA
>> ----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
>> -?????????  ? ?  ?            ?            ? sedb4JEiI
>> -?????????  ? ?  ?            ?            ? sedhqlAcd
>> -?????????  ? ?  ?            ?            ? sedy0KQnt
>>
>>
>> Output in dmesg is:
>>
>> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2
>> /var/log/syslog
>> Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata: Error
>> writing metadata out to lower file; rc = [-13]
>> Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc =
>> [-13]
>>
>>
>> Ecryptfs is configured as follows:
>>
>> merkaba:~> cat .ecryptfsrc
>> ecryptfs_unlink_sigs
>> ecryptfs_sig=[…]
>> ecryptfs_fnek_sig=[…]
>> ecryptfs_xattr
>> ecryptfs_key_bytes=32
>> ecryptfs_cipher=aes
>> ecryptfs_passthrough=n
>>
>> I am using extended attributes to avoid the space waste of 8 KiB per file.
>
> I must warn you that the ecryptfs_xattr_metadata option is rarely used
> by anyone and gets little testing from me upstream. I understand the
> desire to save some space, but you should also consider stability here.
> I'm working to automate some of that testing soon, so there is hope that
> things could get better in this area.
>
>>
>> The underlying filesystem is:
>>
>> merkaba:~> grep /home /proc/mounts
>> /dev/mapper/merkaba-home /home ext4
>> rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0
>> /home/.ms /home/ms ecryptfs
>> rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs
>> 0 0
>>
>> Kernel is:
>>
>> ms@merkaba:~> cat /proc/version
>> Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1)
>
> Ok, I was able to reproduce this on roughly the same kernel version by
> untar'ing the kernel source.
>
> I'll have to do some more investigation into how we can handle this
> error better. ext4 is returning an error when we're trying to create the
> xattr upon file creation, so how we convey that to userspace through the
> creat() return value and how we clean up after ourselves is probably the
> issue here.
>
> Tyler
>
>> (ben@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Sun Dec 4
>> 18:38:24 UTC 2011
>>
>>
>> With encfs or from my local workstation via NFS there is no such issue.
>>
>> Ciao,
>> --
>> Martin Steigerwald - teamix GmbH - http://www.teamix.de
>> gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
>> --
>> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html