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 context=system_u:object_r:user_home_t:s0 Select key type to use for newly created files: 1) openssl 2) passphrase Selection: 2 Passphrase: Verify Passphrase: Select cipher: 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) Selection [aes]: Select key bytes: 1) 16 2) 32 3) 24 Selection [16]: 2 Enable plaintext passthrough (y/n): n Attempting to mount with the following options: ecryptfs_key_bytes=32 ecryptfs_cipher=aes ecryptfs_sig=92868a6a72b0202e Mounted eCryptfs [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 [client]# ll total 12 -rw-r--r-- 1 root root 7 May 28 15:57 foo ----WAIT A MINUTE OR TWO---- [client]# ll total 0 ??? 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 still works. 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 disappearing again. Version-Release number of selected component (if applicable): kernel-2.6.18-92.el5 ecryptfs-utils-41-1.el5
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 specific one.
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 rhel5 box.
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 release.
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 (2.6.29.6-217.2.16.fc11.x86_64)