Copying files encrypted with ecryptfs

Hi. I am trying to use ecryptfs for the first time.
I've created /mnt/backup/secret/ and /mnt/backup/plain/
and copied a directory (called '6') into /mnt/backup/plain/
Now I want to copy this encrypted dir /mnt/backup/secret/6/
to my Dropbox folder.

But using cp -av just copies the bare dir structure with no
actual encrypted files. Same with rsync. sudo makes no difference.
I get

cp: cannot open `6/lists.tex' for reading: Input/output error

errors. This also occurs with target dirs outside the Dropbox.

I don't know where to begin with this. Using Ubuntu 11.04

Please use sshfs. You can remotely mount a filesystem by putting this in fstab:

sshfs#{user}@remotehost:/	/media/{localmountpoint}	fuse	user,auto,_netdev,cache=no,ServerAliveInterval=15,reconnect,allow_other,comment=sshfs 0 0

Try unmounting the ecryptfs filesystem first. From the ecryptfs FAQ:

Q. Can I access the lower files while eCryptfs is mounted?

Accessing the lower files during an active eCryptfs mount is somewhat like accessing a block device on which ext3 is mounted. The kernel allows it, and it may work (depending on what you do with the data), but it is not a good idea.

Originally Posted by rknichols Try unmounting the ecryptfs filesystem first. From the ecryptfs FAQ: Q. Can I access the lower files while eCryptfs is mounted? Accessing the lower files during an active eCryptfs mount is somewhat like accessing a block device on which ext3 is mounted. The kernel allows it, and it may work (depending on what you do with the data), but it is not a good idea.

Thanks for this. (I'd read it, but not understood it.)

I tried this, but get `device is busy' messages.

I don't understand why moving or copying the files is difficult. The manpage says, right at the start,

eCryptfs stores cryptographic metadata in the header of each file written, so that encrypted files can be copied between hosts;

so surely it ought to be easy to do?

I also tried mount --move /mnt/backup/secret /home/myname/Dropbox
This shifted the dir tree, but not the files, to Dropbox and made inaccessible the usual contents of Dropbox.

Maybe I should try sshfs as suggested above, or set up a vpn server on my home machine. What
I want to be able to do is the following: I use two desktops, home and office, a heavy laptop, a tablet, plus other desktops when I travel abroad. My Dropbox has about 30GB of stuff which can safely be kept in plain. I have another few GB of private stuff which I need to be able to get at, and edit, while away from the home machine. ecryptfs seemed like a good solution ...

"Device is busy" means that some process has a file open or has its current working directory somewhere in the mounted (plaintext) directory. It's the same issue you'd run into if unmounting any other filesystem.

You could also try remounting the filesystem read-only:

mount -o remount,ro /mnt/backup/plain

That will be allowed unless there is a file open for writing or a file that is unlinked but still in use by some process.

Originally Posted by rknichols "Device is busy" means that some process has a file open or has its current working directory somewhere in the mounted (plaintext) directory. It's the same issue you'd run into if unmounting any other filesystem.

You can use the command lsof to get the process having files open there. This can also be an open terminal where the shell has the current working directory at this location.

After some experiments to replicate your results, I think you might just have your mount command backwards. It should be:

mount -t ecryptfs crypted plain

or in /etc/fstab:

crypted  plain  ecryptfs  {options}  0 0

You are mounting an encrypted "device" onto the (empty) plaintext directory, not the other way around.
The only way I could duplicate the "I/O error" behavior was by reversing the two mount arguments and thus writing plaintext data directly into the supposedly encrypted device.

Examples in documentation seem, for the most part, to show "overlay" mounts, where the two arguments are the same, making it a bit hard to see just what is going on.