Am Freitag, 16. September 2016 09:27:26 UTC+2 schrieb Raphael Susewind:
> IMHO the safest option is indeed to use a split-dm kind of approach, as
> suggested before: create a loopback file in the dropbox VM, expose this
> via qvm-block to your working VM where you then do all the encryption
> (using standard LUKS) and can either mount the thing right there or -
> for extra security - expose to yet another VM, again using qvm-block:
> dropbox VM: loopback file -> /dev/loop0 -> exposed with qvm-block to
> crypto VM: /dev/xvdX -> dm-crypt -> /dev/mapper/plain -> exposed to
> work VM: /dev/xvdX -> mounted somewhere and used as usual...
> The only caveat is how Dropbox behaves if you have a file in it that
> serves as backdrop for a loopback device - any thoughts on this?
> Raphael

I dont have any references at hand, but back then when I decided to go with 
EncFS, I also looked at the block-device method. IIRC, Dropbox theoretically 
does handle giant files very well (actually it's pretty irrelevant what you 
store), but there were problems with syncing obviously (try accessing this 
device on multiple machines) and also with write-through and general integrity. 
It just had a lot of quirky corner cases and while EncFS + Dropbox isn't 
perfect for syncing either, it has worked flawlessly for over two years now 
(with daily use)...

So for me, EncFS seems the way to go, unless you unmount the file system and 
flush it before activating dropbox but that is kinda unstable from a human 
error perspective...

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to