Dropbox plans to drop encrypted Linux filesystems in November Linux users are calling on Dropbox to reverse a decision to trim its filesystem support to unencrypted EXT4 only. The company's supported file system list, here, is missing some formats – including various encrypted Linux filesystems. Until that list was revised, Dropbox said it supported NTFS, HFS, EXT4, and APFS on Linux; …
This post has been deleted by its author
This sounds entirely like a company which wants to reduce the amount of testing it does each time an update is brought out. Unfortunately for them, anyone who is using an encrypted Linux partition on a laptop is going to get hit by this, and will have to find an alternative supplier.
Changing cloud storage suppliers is a lot of faff and trouble, so even if they do reverse this idiotic decision, a lot of people will avoid them for a very long time just from inertia.
Has anyone any suggestions as to a less pig-headed cloud storage supplier?
Exactly. This is one of the situations where too many options bites back. Linux has only a tiny share of the desktop market, but while Windows and macOS - 95% of the desktop market combined - have only one file system each (and when Apple switches OS, users switch), Linux has many, with different combinations. It could be really too expensive to code, test and maintain them all for so few users.
If the feature Dropbox needs is xattrs, it is a fair requirement. It is just like requiring some other property of file systems, like a certain minimum file name length. But then it it should run just fine on any Linux file system that supports the xattrs API, not just ext4fs. Most non-ancient native Linux file systems do so.
Too many options it not an issue here. Only the API matters, in other respects a user level component like Dropbox must be ignorant of the particular underlying implementation.
I hope you don't manage software. The same API doesn't ensure the underlying layer behaves exactly the same.
You need to test each supported combination, to ensure nothing weird happens. And yes, it means also you need to test NTFS on each supported Windows platform, in 32 and 64 bit flavours.
Multiply Linux file systems for the encryption layers and the distro versions, and then double it for 32 and 64 bit implementations. It's a lot of stuff to test - for relatively few users - I guess you don't want to lose files because of am undetected bug...
> You need to test each supported combination, to ensure nothing weird happens. And yes, it means also you need to test NTFS on each supported Windows platform, in 32 and 64 bit flavours.
So should one do this for *every* program that reads or writes files? Same thing. Normal open, close etc are also part of an API specification that abstracts away the underlying file system implementation.
Building large software systems is impossible without relying on such abstractions.
If what they need is xattrs then it sounds like there's an easy way out. They could, rather than saying that 'Dropbox will only work on filesystems x, y & z' say 'Dropbox needs xattrs to work. If the filesystem you are using it on has xattrs and supports them in a way compatible with ext4, then Dropbox should work. However we can't test all the Linux filesystems: the ones we test are x, y & z, so those are the only ones that we will support Dropbox on: if you have a problem with it running on some other filesystem then, at our option, we may choose to reject support requests'.
However one of x, y & z should be an encrypted filesystem, for sure.
Wasabi is working well for me. They have a client for Mac/Windows, but under the hood it is just S3, so you can use whatever tools you wish (s3fs/rclone etc).
Only caveat is $4.99/mo minimum (but you get 1TB for that).
I changed to Yandex-Disk. It syncs just as quickly as dropbox. And I have tried alot of them. This really drives me crazy. First I have to reformat my drive from btrfs to ext4 . And now it will NOT sync on a luks encrypted drive. I really dont understand why google does not create a Google Drive linux client. They have a client on their Linux phones. Why not my Linux desktop? Anyway, I will not be using Dropbox anymore. For anyone looking, check out Yandex-disk it works very well and they give you ALOT of space.
if feature maintenance is a problem, then re-design the thing so that maintaining such "features" is no longer required. Works on all platforms, using a common method. Simple, right?
How does 'rsync' do ITS magic? They should JUST do that. makes sense to me.
[as I understand it, rsync compares file size and SHA hash - if they differ, it needs to be sync'd - and source control systems have well-tested methods of storing/tracking version info if you need that, too]
this makes me consider that a paid-for github repo would make for good off-site backup, too... [or NOT github if you want a non-Microsoft solution]
I pretty much guarantee this was an accounting-based decision. They weighed income from users using these very rare file systems vs the cost of maintaining support and found that it wasn't worth it.
It's not as if these users can't just create a separate partition just for Dropbox or use Dropboxes web UI. I use Dropbox on a regular basis and never installed the app. Anyone paranoid enough to run a fully encrypted FS wouldn't want to store sensitive data in an online file locker. And anyone with a real reason to run a fully encrypted file system wouldn't use Dropbox on the same system. I imagine the number of effected users is very low, but probably also very vocal.
If you choose the latter, you probably want to share the underlying encrypted directory, not the unencrypted virtual mount point. That way the NSA Dropbox will only see a bunch of gibberish files with numerical names and unintelligible encrypted contents.
The beauty of this solution is that it works with absolutely any Cloud service, regardless of whether or not they support encryption.
b) Use EncFS to encrypt the directory you're sharing with the NSA Dropbox (this also works under Windows)
If you choose the latter, you probably want to share the underlying encrypted directory, not the unencrypted virtual mount point. That way the NSA Dropbox will only see a bunch of gibberish files with numerical names and unintelligible encrypted contents.
The beauty of this solution is that it works with absolutely any Cloud service, regardless of whether or not they support encryption.
----------------------------------------------------------------------------------------------------------
Aha! Bravo!
I figured there had to be a way of doing something like this!
Just wanted to say something along those lines myself.
In fact, if you're sharing your data with DropBox in the first place, never mind EncFS, you should be encrypting your files individually - otherwise, every time you open the EncFS 'vault', as long as it's open, they've got access to the unencrypted datastream traversing their network anyway, so, it's academic what you do.
"they've got access to the unencrypted datastream"
I'm pretty sure they have no access to the unencrypted virtual mount point, since that is only available locally, unless that is the directory you're sharing with them (which you shouldn't). If you're only sharing the raw encrypted data then that is all they see.
Accessing your own data from multiple systems is simply a matter of using the Dropbox share as the source for the FUSE loop mount, having some EncFS implementation (available on all platforms, AFAIK), then providing the correct password. Again the unencrypted data should only be visible locally (unless your system has been in some other way compromised).
Good point(s).
Of course it probably won't surprise you to learn that I'm pretty larey of mounting filesystems of data that are then wide open so long as they''re mounted.
FDE is great when the drive's unmounted but the drive might as well never have been encrypted in the first place once it's mounted. The same goes for EncFS type solutions (VeraCrypt/whatever).
Mostly I don't worry about it (assume my defences are largely sufficient to deter the casual port-scan and to mitigate a 0-day browser exploit might do by not browsing with elevated privileges) and convenience trumps security for most stuff (FDE will do) but if the data is seriously worth keeping private then I encrypt individual files - they might be compromised whilst I'm working on a copy of them but at least none of the others can be.
I don't think that any 3 letter agency cared for your disk encryption when files are stored in DB. Now, having these files encrypted before the upload could possibly get their attention. No idea why DB would care for the encrypted file system though - the app handles whatever OS provided and shouldn't depend on underlying FS (as long as some minimum requirements are met).
It's not the TLAs I'm concerned about but industrial/professional espionage or, more likely, the inevitable incompetence that leads to millions/billions of customers' data being exposed (think Yahoo/Equifax/whoever).
If I have data that is passing through DB on its way to/from a customer/client/patient/whoever, I want to know (not just hope) that it's secure - quite apart from "it's the principle of the thing, damnit", at the very least I don't want to open myself up to a lawsuit (or these days GDPR prosecution) - having that leak splashed all over the Press/Media will not be good for my potential earning capacity either (potential future clients won't be so interested in my services any more).
If you are using non free-as-in-freedom product, don't be surprised when terms of use or quality of product or supported platform(s) suddenly change and you are out of the boat. I already been there - with Ubuntu One (remember when it offered storage + sync?). That being said, my dropbox is working on EXT4 on top of LUKS (on top of LVM... oh well), so I'm sure it will continue to work as intended. But if some day I won't be as lazy as usual, I will definitely switch to something self-hosted.
I'll bite ))
Dropbox syncs to directory, usually located in your home directory.
Encrypting your home directory (and, better, your whole disk) is a must: not to protect from NSA or KGB or whatever, but to protect your data on the laptop in case it will be stolen or lost. And dropbox is perfect fit to sync occasional notes between home/laptop/work.
Pretty much this. I mostly use Dropbox to keep a replica of my various character sheets and game notes. Because I've learned that lesson the hard way. Pretty much everything else is either easily replaceable (all the software, PDFs, etc.) or sensitive and so only backed up locally. And for this purpose, Dropbox is great since it means I can go up to any PC anywhere and be ready to play or run an RPG within 30 minutes, with all of my character sheets, notes, etc. intact.
So they're encrypting their filesystems to keep them secure, then handing them over to Google in the cloud? What?
Isn't that like putting my spare key around the corner instead of under the doormat, then putting a sign up saying "key is here"?
-----------------------------------------------------------------------------------------------------------------------------------
No, it's like giving your bank an encrypted copy of your will, but not the key.
The key copies go to your executors.
It's about storage diversity, redundancy, accessibility.
If the encryption is secure, and you keep the key safe, then it works.
I'm a Debian kinda person, but I know that RHEL uses XFS as its default filesystem for recent versions - so this seems like a fairly dumb move. And OpenSUSE seems to use XFS for /home in recent versions.
They should at least support both ext4 and XFS on that basis alone.
The xattrs reason is plainly not true, as there's a bunch of filesystems that support xattrs perfectly well. One interesting comment I saw on Reddit seems to have a possible answer:
https://www.reddit.com/r/linux/comments/966xt0/linux_dropbox_client_will_stop_syncing_on_any/e3yx2gs/
Basically Dropbox may have used a particular attribute as an identifier. That attribute is static on ext4, but may change on XFS. If that's the case then this is nothing to do with xattrs, and everything to do with a bad assumption on the part of Dropbox's development team. (I'm guessing they use it to determine whether a file is the same but changed versus a completely new file which replaced the old one.) They assumed all filesystems would behave like ext4, and now they're finding that this isn't the case and there are some edge cases they didn't expect.
If this is the case then rather than fix the problem they created, they've decided just to shift the blame and drop customers who they failed...
It wasn't told (some of commenter in that thread) that the reason for excluding other filesystem was the lack of extended attributes (but most of FS in use do support Xattr). So the reasoning behind the announced change is lame.
Also, on Linux systems, the client auto-upgrading feature requires that /tmp be miunted without "noexec". Otherwise it begins to repeat downloading new version again and again, failing at execution step. It took several weeks of exchanging messages with Dropbox support, before I found the problem myself (and no solution, save disabling "noexec").
Personally, I encrypt whatever is stored on Dropbox, so even if they leak those files of mine, it's not that dramatic. But I assume many a people don't bother with that.
Yes, yes, yes ... but anything that thinks it is wise to execute something in /tmp is NOT to be allowed near computers, so my take on it ? Don't use software that expects to be able to execute stuff in /tmp .... simples - brain-dead devs cannot make decent software, don't take the risk.
I think this is a good move.
For some unexplained reason, some people seem to think that because of their having made a little effort to secure data on their local disk, it is somehow still secure when shared with dropbox. It is only a few extra minutes work to set up a non-secure partition on Linux that can be shared with dropbox which would help make it (more) obvious to the user that no matter how secure your data is locally, anything outside that security net is, well, outside that security net.
Just because dropbox isn't 100% secure, doesn't mean your local version should also be weak.
-------------------------------------------------------------------------------------------------------------------
This is backwards.
Just because dropbox isn't 100% secure doesn't mean you should fail to make the things you put there intrinsically secure regardless of who can see them.
"Just because dropbox isn't 100% secure, doesn't mean your local version should also be weak."
I am afraid that you have that backwards. Security is as good as its *weakest* link, not its strongest. It doesn't matter how secure your data is locally, if you leave it unencrypted on the bus, in the cloud or on dropbox, then it is not secure.
no matter how secure your data is locally, anything outside that security net is, well, outside that security net.
----------------------------------------------------------------------------------------------------------------
Not if it is protected by strong encryption.
That's the whole point, isn't it?
Encryption protects contents even when an encrypted representation falls into hostile hands.
Already we have to enable Google XSS just to log in on the web.
Already official support for the Debian client has been dropped and the version frozen.
Now we see a pruning of *encrypted* filesystems of all things. Unencrypted I could understand, but ENCRYPTED (he shouts) is just two fingers up to us.
Dropbox, you are driving away your foundational user base, the geeks who seek out and support independent and privacy-strong providers. This is no way to grow your reputation or bottom line. You are undermining your USP in just about the most efficient way imaginable.
Yes, I'm running LUKS encryption on top of my BTRFS partition
Right, I'm not an expert on this, but I've learnt there's no better way to learn, than to be wrong on the internet.
LUKS is a full disk (or full partition at least) encryption system. Surely the filesystem (BTRFS in this case), is on top of LUKS, not the other way around? After all, if I run blkid then it tells me that the encrypted partition is TYPE="crypto_LUKS", instead of ext4.
Contrarywise, as far as the running OS is concerned the filesystem is vanilla ext4, so I don't see why Dropbox would have a problem running on it. Indeed, I've yet to get a warning from Dropbox on any of the machines I'm responsible for, most of which are using ext4 on top of LUKS.
Still, I don't see why Dropbox can't continue to work on any file system with extended attributes, especially as it's been working on (eg) BTRFS systems already.
This post has been deleted by its author
Well, by 'learn', I mean, 'often get aggressively patronised by people who think that you're an idiot for not knowing $complicated_thing', but if you ignore the vitriol you can usually learn things.
If you say "does anyone know how X works?" you might get a couple of replies, which might be helpful. If you say "X works like this!", you'll get loads of replies telling you why you're stupid, and terrible, 'oh and by the way it actually works like this'. So, less polite, but sometimes more useful if you don't mind holding your nose and picking the nuggets of useful advice out of the shit.
Ta for the beer tho ;)
I wouldn't trust Dropbox as far as I could throw it, just like I don't trust GMail and all the rest. Aside from the very valid privacy concerns, you are at the mercy of someone else getting taken over by someone you don't like and/or deciding to shut down their service from one day to the next (e.g., Drop.io, Parse, Panoramio, etc., etc., etc.)
Personally, I am well immersed in the Nextcloud ecosystem. Of those partners of us who have implemented a cloud solution, about half a dozen of them, all bar one use Nextcloud. The remaining one uses their own in-house solution developed maybe ten years ago. I also use NC privately and I am rather satisfied with it.
It sounds really stupid, I use ZFS on FreeBSD which I don't believe is supported and on Windows I use EFS and Bitlocker with OneDrive for Business since one of my employers provides it so I don't particularly care, but it sounds like simple incompetence, like Dropbox laid off too many developers and the ones they have left aren't good enough to support more than one filesystem, and a basic one at that.
Thing is, its really short sighted, encrypted filesystems are already much more the norm rather than the exception anymore which is only increasing in terms of market share, and they're artificially cutting off their potential users.
Oh well. Sucks for them I guess.
I've been dropping Dropbox slowly over the last couple of months. Going to switch it off by end of this month now. I use Syncthing instead. N-way filesystem sync between PC, laptop, home backup and remote virtual server, all of which use different encrypted file systems and three different OS between them. Has been working like a charm. Oh, and the transfer off-site goes via OpenVPN link between home router and virtual server. Not that I have reason to believe that Syncthing's in-transit encryption of traffic isn't good enough, but I trust OpenVPN to be better tested and scrutinised.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
