What the heck. Anyone has more information about that? Any announcement? And why would it fail to work on an encrypted (LUKS?) ext4 FS when encryption seemed to me to sit below the filesystem (since AFAIK ext4 doesn't support encryption itself)?
”If you received a notification on Linux and you are running ext4, it may be because you are also running ecryptfs. ecrypfts is not supported. However, we support full disk encryption systems, such as LUKS for Linux users.”
Source: https://www.dropboxforum.com/t5/Error-messages/Dropbox-clien...
[1]: https://www.kernel.org/doc/html/v4.19/filesystems/fscrypt.ht...
[2]: https://wiki.archlinux.org/index.php/ext4#Using_file-based_e...
"Unencrypted or decrypted ext4" might be slightly more accurate (although I guess it maybe sounds like you need to remove encryption, not that you just need to decrypt files in memory).
https://www.dell.com/community/Linux-Developer-Systems/XPS-1...
There is almost always at least one unencrypted partition on machines with full-disk encryption, since the boot loader and then the decryption routine have to be launched from somewhere. And yes, OEM recovery partitions or similar laptop-specific needs are another case.
Full-partition would be a more accurate term than full-disk.
I wouldn't know where to start if you want to use ubuntu or another more user friendly distribution though.
Migrating away from that to block-level "full disk" encryption basically requires copying all your files. If you're using <50% of your disk and you feel comfortable doing tricks with partition resizing you can do it, otherwise the best approach is to back up your files (hopefully to encrypted media...) and restore them.
Ceph/RBD with the filesystem of your choice that supports xattrs is pretty much the only way to get full application compatibility.
I guess power users are not the target market.
https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/
I thought the whole point of an encrypting filesystem was that applications using it would not need to care about such things? Unless you're going below the FS abstraction and actually accessing blocks of the device directly, it shouldn't matter.
For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.
Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)
Another example of features not implemented everywhere is the cornucopia of file locking APIs which is why SQLite doesn't officially support being run on NFS.