Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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,
Quote:
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:
Code:
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.
"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:
Code:
mount -t ecryptfs crypted plain
or in /etc/fstab:
Code:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.