Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to do live synchronization of an encrypted directory with a server, such that the server only sees encrypted data.

Suppose I put the underlying ecryptfs data in:


And I mount that directory at:


Can I update the files in .Private (e.g. using rsync) and expect unlocked to reflect the changes? Or is this going to just mess things up? Are there better alternatives for live synchronization of encrypted data?

UPDATE to clarify:

I want to only ever transmit encrypted data to the server -- the server is not trusted. So I want to see:

 client <-- encrypted data --> server

There may be more than one client updating (decrypted) files; hence the live-synchronization desire:

         \--- encrypted data --\
         /--- encrypted data --/

So the client has a directory containing encrypted files -- chunked the way ecryptfs does it:

                 |--- ECRYPTFS_FNEK_ENCRYPTED.Fabcde.../
                 |                                    |--- ECRYPTFS_FNEK_...
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Flaksd.../
                                                      |--- ...

This is mounted with ecryptfs:

                 |--- secret_file_1
                 |--- secret_file_2

Now, client1 is busily making changes to files in unlocked. When the client makes changes, the underlying encrypted files in .Private change as well. So a local inotify or some such notices the changes and rsyncs the encrypted base files in .Private to server. The server, aware that client2 is also listening, notifies client2 that it should pull changes.

So my concern is: If client2 pulls down the underlying encryptfs chunked files into .Private while it is mounted in unlocked, I suspect this will cause problems, no? This would require client2 to unmount unlocked prior to syncing, which defeats the whole "live synchronizaton" idea.

If so, what are good alternative techniques for efficient syncing of diffs of an encrypted tree?

share|improve this question
up vote 2 down vote accepted

According to Tyler Hicks (one of the maintainers of eCryptfs) it is currently not safe to modify underlying filesystem (lower filesystem in eCryptfs terminology):

It would be good if eCryptfs could detect lower file data changes and update the cache to see the file updated.

Even if we could detect them, how would we mediate them against dirty eCryptfs pages? How do we know what is the most up-to-date data?

Unfortunately, direct modifications to the lower filesystem are simply not supported. If a modification doesn't go through the eCryptfs mount point, we cannot be expected to know about it due to the eCryptfs architecture.


share|improve this answer

To update files in the ecryptfs filesystem you need to update them in the mount point - in the encrypted filesystem you would need to update the entire thing at once, as it has no concept of files or directories - it is just a large chunk of data.

Yes, you can use rsync to back that data up somewhere, but in order to read or write a particular file you need to mount it.

You can mount it from various different places (probably best not to try this simultaneously :-) so why not use a shell script which mounts, rsync's the relevant files and unmounts whenever relevant files are updated?

useful info here

share|improve this answer
"in the encrypted filesystem you would need to update the entire thing at once, as it has no concept of files or directories - it is just a large chunk of data.": I'm pretty sure that's not true. According to the article you link to, ecryptfs is a "Stacked Cryptographic File System", which is distinct from a block-device encryption which it sounds like you're describing. The difference: . I've updated the question to provide more detail. – user67641 May 28 '11 at 20:10
@user67641 - ah yes, you can do it that way as well. My bad - I don't. In eitehr case you should be correct (caveat - I haven't tested this yet): client 2 would need to unmount prior to syncing. And I don't know a workaround - so my answer isn't going to help you much at all. Will try and get some time to test it. – Rory Alsop May 28 '11 at 20:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.