Red Hat Bugzilla – Bug 448797
Files created in eCryptfs overlay atop NFS disappear
Last modified: 2012-01-09 17:03:16 EST
Description of problem:
File created in an ecryptfs overlay atop an nfs share disappear.
Two machines involved: "server" is an nfs server, sharing out "/data", "client"
is a workstation mounting /data from server.
The client has /data mounted from the server, and now creates a directory
/data/encrypted, and proceeds to mount an ecryptfs overlay atop /data/encrypted
(using selinux xattr work-around in bug 448787):
[client]# mount -t ecryptfs /data/encrypted /data/encrypted -o
Select key type to use for newly created files:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Select key bytes:
Selection : 2
Enable plaintext passthrough (y/n): n
Attempting to mount with the following options:
[client]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 41G 1.6G 37G 5% /
/dev/sda1 190M 29M 152M 16% /boot
tmpfs 437M 0 437M 0% /dev/shm
xenon:/data 101G 41G 55G 43% /data
/data/encrypted 101G 41G 55G 43% /data/encrypted
[client]# echo "wasabi" > /data/encrypted/foo
-rw-r--r-- 1 root root 7 May 28 15:57 foo
----WAIT A MINUTE OR TWO----
At this point, an ll on the server side works just fine, shows the encrypted
file and everything. Oddly enough, trying to cat the file client-side actually
Unmounting the ecryptfs overlay reveals the file to ls again. Re-mounting the
ecryptfs overlay results in the file being there for one ls iteration, then
Version-Release number of selected component (if applicable):
Whoops, this should be against kernel, not ecryptfs-utils.
Mike has an nfs-related patch that I have rolled into my 2.6.26 ecryptfs
backport for 5.3; testing it now. So far this simple test seems ok.
Yep, looking much better here now too.
copying a kernel tree onto ecryptfs-over-nfs-client-mount worked, but "make
clean" exploded. We still have nfs problems, though apparently not this
I've successfully copied a kernel source tree onto an ecryptfs-on-nfs mount w/o
a problem so far, now doing a kernel build. First thing that jumps out is
constant spew about files having modification times some random amount of time
between 2.5 and 11 seconds in the future. Will give a make clean a try once the
kernel build is done. For the record, the nfs server in this case is another
The 'make clean' exploded here too, filed bug 450144 for that problem. Still
need to poke at the modification time thing, may just have been a generic nfs
thing, since the clocks on the server and client weren't in sync.
Yep, chalk up the modification time thing to the server and client having clocks
a ways out of sync. All's well on this front if they're both keeping time correctly.
Moving this to 5.4; still no fix upstream and I've not been able to resolve it. We'll need to release-note ecryptfs in 5.3 with caveats about NFS, I think?
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Note, RHEL5.3 will have a patch to disallow mounts on NFS due to the severity
of the problems.
Updating PM score.
Moving this off to 5.5. AFAIK it's still broken upstream, and we have patches to prevent nfs mounts, so customers won't see this (with the restricted ability to use nfs, that is)
Still broken in Fedora 11 (18.104.22.168-217.2.16.fc11.x86_64)