If instead you used dmcrypt and encrypted the whole device or partition you'd probably have no issue as it looks just like any other EXT4 FS to the system.
Would be a lot better if they specified what features they need the underlying FS to support.
That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.
> "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.
"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.
That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.
Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.
I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.
"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."
Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway.
Remote interaction is then required to bring the VMs on that system up.
I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.
This would certainly be more work to set up than vanilla full-disk encryption, though.
a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK)
b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.
On the O365 Personal/Home or direct OneDrive plans, it looks like your data remains available but read-only for 3 months, then your account is "frozen." You can do a one-time 30-day "unfreeze" to get access to download/delete (to get under your quota), then it gets "frozen" again. Eventually it'll be deleted, but I don't see documentation for how long that takes. (source: https://support.office.com/en-us/article/what-does-it-mean-w... linked from https://support.office.com/en-us/article/OneDrive-storage-pl...)
However, my IT company onboarded a media-intense client with insync and it has been nothing but a nightmare. There are hardcoded limits (like only syncing two files at a time, IIRC) that make it effectively useless for anything beyond small, personal use. It's cheap and you get what you pay for.
rclone is rsync for cloud storage services -- https://rclone.org/
I also use Syncthing, which I am very impressed by, it works really well.
Maybe they’re doing uncommon stuff with ’em that uncommon filesystems cannot cope with... ;)
Thanks, I updated the title.
Also, when you consider that being offline for an extended period of time means that your files are not being synced, then the purpose of Dropbox is somewhat defeated. Basically Dropbox can't sync without connectivity and if you have connectivity then you would have access to the Keybase "file store" anyway.
Yeah, no, I don't think so. If my bus or train goes through a tunnel, losing my dotfiles or my OneNote notebooks or whatever else is pretty bad.
Forget first world problems--"people almost always have connectivity" is some...like...zeroth world stuff.
I really doubt that in most modern environments (i.e. where smartphones are pervasive) that you are going to go very long without connectivity in an unplanned scenario.
"I copy files out of it to get around that it's not good at what I'm trying to use it for" is not a super winning argument, either.
KBFS is fine. I use it for stuff like SSH keys. It's fine. It's not Dropbox and it isn't substitutable and it doesn't need capes.
The point I was trying to make is that for many people being able to copy back and forth between a local folder and a mounted directory is no different than what they do everyday at work with networked folders. Many people are just moving the occasional document, picture, or folder. For those people Keybase could definitely work as a Dropbox replacement. I don't think the typical Dropbox user is expecting their ZSH profile to be omnipresent on their multiple computers/laptops/tablets.
You may be misunderstanding intent.
Also, to be clear, you could use the mounted files directly, but you just have to be aware that if you lose connectivity you may run into issues. If I was traveling somewhere and I'd like to work on a document in transit then I would recommend copying that to another folder on your local machine first.
Being on a NYC subway train is an even more interesting case, because depending on the precise client setup there's often intermittent or bad connectivity but rarely a good sustained connection between stations.
As in most of the world, smartphones are pervasive in both of these contexts.
Mobile and computer apps used to support these cases a lot better. As Bay Area connectivity has gotten better in those areas where well-off techies congregate (e.g. not underground Muni Metro), apps have gotten much worse at this except for apps targeting developing countries like India and Africa.
I want my computer to do scutwork for me instead because that's its job.
You're describing useful workarounds for the status quo when one can foresee dealing with these situations occasionally. Those are certainly good to document.
But they're workarounds and not true solutions, especially not for frequent needs.
Sorry for letting a rushed comment perpetuate the common Western stereotype of conflating all of Africa as if one single thing.
One of the machines even runs an old version found in Debian stable repos, but there has been no issues syncing with machines running newer versions.
Only downside for me is that there's no iOS client.
Long term I do still plan on moving to NextCloud, the core dev team from owncloud moved over and I've always been happy with OC, but I need the time to actually figure out why I'm getting sync errors with the suggested setup after following all the suggested fixes.
That said, Ext4 is still supported, just not with encryption.
It's a terrible idea to not turn on hard drive encryption. Anyone who gets their hands on the machine can read and write to the drive by booting it with a thumb drive.
With the fragmentation of Linux, even the "most popular" distro may hold a tiny market share. The guys at dropbox probably know far more about their users than what is reflected in some arbitrary popularity contest, so I doubt it's either ignorance or stupidity that led them to this decision.
Edit: Actually I can't find that it was ever the default, but it was a pretty prominent option so I assume this decision is going to mess with a ton of customers.
Both are checkboxes, though, so one could select whichever they wanted. Full disk encryption is the most sensible one, though (better evil maid protection).
I know that I installed Ubuntu with default settings, and was pleasantly surprised by that. Not sure about the exact version though.
I've heard several admins flat out scoff at the idea of using it.
Make sure you have backups with a reliable fs.
Step 1: "You can now use dropbox in fewer scenarios than before"
Step 2: ???
Step 3: More customers paying more money
Dropbox is paid for and used in various places I work and personally because of the Linux support. (Their competitors ignore Linux for some reason.) In my case step 2 is going to be them losing at least $1,000 in annual revenue. And they won't have that the next year either (ie recurring revenue). Nor will they be part of future options for work or personal.
News headline - "Company removes X feature"
Hacker News comment - "Company is sure to lose customers over this!"
News headline - "Company reports record profits"
If Dropbox really wanted to save some money, they'd fire their accountants and just rely on armchair HN comments to tell them how well their financials are doing.
Seriously. No company this large can justify supporting a fringe operating system to their investors and shareholders. In a perfect world they would open source what they did to support it so others could pick up the work and integrate it into other products. Oh well.
In places (eg tech) where there is a Linux user base (eg the developers, devops etc) then Dropbox was the main realistic solution for the whole company. It is now just a random entry in that list, and there is no compelling reason to chose them over the others. Heck Google and Microsoft become the top choices simply because that is where the user accounts, email, calendars and then docs end up.
We don't know just how big this "Linux" group is and it certainly is small (your point). I believe the resulting effect will be larger than Dropbox expected. For example the Windows users I collaborate with do so using Dropbox because I use that for Linux. Dropbox might think they are losing me as one user, but they are also going to lose those Windows users too (they find OneDrive far more convenient as it is already there on Windows and in your Microsoft account).
I'd also argue that in aggregate Linux users are more technical and more likely to be influencers. So again that is more future revenue dropbox won't get, unless they get better than their competitors. Recurring revenue is hurt and helped much in the same way as compound interest works. As you add up the missed revenue over the years, it does get to be a big number. And that money likely went to someone else strengthening them. Remember that Dropbox grew essentially by word of mouth. They are going to lose some of that.
The open source approach would be nice, but I am skeptical. Why would a developer spend their time helping dropbox (the server side won't be open source), and not something completely open? The Linux clients done as 3rd party projects for their competitors seem to be far less complete and reliable compared to the vendor implementation.
TLDR: Dropbox did have a unique selling point in their Linux support. Without it they are indistinguishable from their competitors.
They are only partially supporting Linux already (eg no SmartSync). They are now removing support for the default configuration on many existing distros. They are removing support for setups that have worked for years, and earned them much revenue. It is their business and they can do what they want. Linux support is what distinguishes them from their competitors. And now they will lose future revenue from me and others who have posted here about it. Also note that their technical explanation is complete nonsense which is exacerbating the problem. Hopefully they will revisit the decision, or communicate in more detail what the problem actually is. I have no doubt that Linux will fix whatever it is.
Ubuntu doesn't use ecryptfs (or even support it afaik) by default.
This does not appear to still be the case based on testing just now (creating a folder named ".foldername", containing a file named ".testfile" then verifying that they've synced up to OneDrive). Several years ago it didn't support syncing folders with a . in the name, but that was resolved 3 years ago.
With Microsoft's relatively new focus on Git, I can't imagine that problems with repositories stored in OneDrive folders would remain unfixed.
I will note that there are names that Windows Explorer won't let you create - notably, names beginning with a ".". That's an Explorer issue, not a OneDrive or filesystem issue - you can create such files and folders programmatically or from a command prompt.
dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...
I mean, the Linux manpage itself says it's stable and can be used, with the inode number, to uniquely identify a file. http://man7.org/linux/man-pages/man2/statfs.2.html
I'm not surprised, though. Fancy copy-on-write filesystems like btrfs have some other subtle gotchas. If you allocate (like, really, not as a hole) a big file on btrfs and mmap it for write, you might see a SIGBUS upon writing because btrfs needed to recompress a block and the new compressed block didn't fit where the old one did.
I've gained a new appreciation for the predictability and simplicity of ext4.
Once saw a system that used inode numbers as "unique identifiers for files on local disk" and it turns out that on Linux / ext filesystems, they're not unique (they get reused if you delete a file and then create a new one). That team just decided to not support Linux at all.
There are even third parties that install it and manage it for you.
This is a shame because I just started using Dropbox significantly more to back up shared photos. Time to search for something else, I guess.
It is (funnily enough) even possible to enable _both_ kinds of encryption simultaneously.
I'd say that they don't use full-disk encryption _instead_ of home folder. They just prompt for it sooner (and it is not the same thing if you have a modestly old machine, or a machine you share with other users).
Edit: It's listed under "Other base system changes since 16.04 LTS" https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes
Atleast the ubuntu server does that, though I wouldn't enable that either way since it's a pain to deal with from the outside.
I'm assuming encryptfs-ext4 has some attribute issue that prevents them for doing efficient deltas. That aside, what's the use case for encryptfs at all? Isn't it strictly worse than LUKS on the underlying volume or a volume file mounted via loopback?
>The supported file systems are NTFS for Windows, HFS+ or APFS for Mac, and Ext4 for Linux.
>A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience. (emphasis mine)
XFS may support xattrs but that doesn't mean that Dropbox officially supports it. They are pretty clear on ext4 being the only supported filesystem.
Edit: added link to the proper comment in the Dropbox thread
If Dropbox go ahead with this I'm bailing. The only reason I use a managed service like this is so I don't have to care about the technical details (filesystems etc.)
I was expecting to still be using Dropbox for a while after that, but it's been surprisingly low maintenance after the initial setup, and it has replaced it perfectly for me :) Highly recommended for anyone bothered by this change.
Of course you can do security for isolation on top of it any time, and sure, you won't get security updates after a while which would be nice, but there are tools to secure an outdated app in other ways either.
It is nice to know where my data is.
If you're willing to invest setup effort it might also be worth considering Tahoe-LAFS's "GridSync" which seems to be making some progress as of late.
Unlike what their name (rsync) suggests, they do seem to support Windows clients and aren't *nix only:
1 - https://www.rsync.net/resources/howto/windows_backup_agent.h...
The point of rsync.net is that you can log onto any unix system, anywhere, and interact with your cloud storage - with no software installation or configuration necessary.
The Windows Backup Agent works very well and has recently been updated but the documentation you are seeing reflects the fact that it is a secondary function here at rsync.net that is mostly provided for the convenience of customers in mixed environments.
We are not a dropbox alternative.
This is a weird, known issue that somehow keeps cropping up on our init7 network connection specifically to scandinavian countries.
I'm sorry we couldn't resolve it.
If you can stand your data being in the United States, our Denver location has a 10gb he.net fiber connection which is God's own Internet. Recommended.
To my mind, the Android app leaves a bit to be desired. Usually you don't want your phone to hold local copies of everything in the shared folder(s) as it is usually space constrained. You want to be able to view and pull files down as desired (possibly with the option to flag individual files to always be cached locally).
Like most open source software: don't bother with the "apps" just install it in termux the same way you would on any other computer.
Are you saying dropbox works without computers O_o?
> provision enough storage to hold everything
It's true that on all your clients put together, you need enough space to have one copy of your data; where for dropbox you can have one single sparse checkout and let their servers hold the full data set. I've never seen that be an issue in practice though - on the contrary, my laptops have enough space to hold all my data, and my dropbox account doesn't, which is why I went to syncthing in the first place.
> secure them
What security do you need to add to syncthing that you don't need for dropbox?
> make sure you have a backup plan
I guess dropbox counts as having offsite backup implicitly; personally I'm using syncthing between a few laptops and desktops in different locations and counting that as the off-site backup plan.
I'm saying that Dropbox does not require you to run every computer yourself. If your house burns, floods, gets burgled, etc. not losing every copy is a really nice benefit for the average person. Not needing to make sure that their laptop is running at the same time as a desktop computer is similarly nice for being able to depend on having n > 1 copies.
> > provision enough storage to hold everything
> It's true that on all your clients put together, you need enough space to have one copy of your data; where for dropbox you can have one single sparse checkout and let their servers hold the full data set. I've never seen that be an issue in practice though - on the contrary, my laptops have enough space to hold all my data, and my dropbox account doesn't, which is why I went to syncthing in the first place.
It definitely depends on the user and is less of a problem as SSDs get larger but I definitely know people who had things like large photo/video libraries which they didn't want to have taking up 80% of storage on every computer they own.
> > secure them
> What security do you need to add to syncthing that you don't need for dropbox?
Two aspects: one is relatively low-impact but still worth making sure you're comfortable with any risk of data loss. If you use FDE on your phone / laptop but someone steals the desktop which has all of your synced data on it, is that a problem? Do you forensically wipe drives before getting rid of them? Dropbox's data is encrypted at rest and since they're hosted in a proper data center you don't have to worry about someone stealing a copy as easily as breaking into someone's apartment.
The other is more important now that ransomware is an industry: if you get malware, how robust are your recovery options? Simple versioning doesn't help if, say, the malware touches a file multiple times or if the versioning system wasn't designed to handle malice and so e.g. an attacker can just empty the trash or overwrite the old versions too.
One nice thing about the hosted model is that it has a completely different trust chain so even if you're totally compromised it doesn't allow them infrastructure-level access. That's far from perfect but enough people have recovered deleted Gmail messages, Dropbox files, etc. that it's worth asking whether you're comfortable about your data recovery options in any comparison.
> > make sure you have a backup plan
> I guess dropbox counts as having offsite backup implicitly; personally I'm using syncthing between a few laptops and desktops in different locations and counting that as the off-site backup plan.
That probably works for most scenarios other than a bad security compromise but how frequently do you verify those copies? Does syncthing have checksums to ensure that the copy you think you have hasn't been corrupted?
Again, I'm not saying that syncthing is a bad choice, only that “It works better” is a very broad claim which is clearly not true as a general statement. Convenience and reliability have significant value to most people.
That's a vague assertion that can apply to anything.
Syncthing can ignore directories/patterns at the local level.
And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.
> have a backup plan
Another non-sequitur. Either tool can be part of a backup solution.
It's a very specific assertion which does not apply to every thing: with syncthing, you need to operate every piece of the system. With a cloud service, you are delegating that to other people, presumably professionals. That's a big difference for most people and it has significant implications for things like backups — e.g. if someone breaks into your house and steals two computers, did you just lose every copy of your data?
> > provision enough storage to hold everything
> Syncthing can ignore directories/patterns at the local level.
That's an unrelated topic. This is about the total size of your data and whether it fits on multiple devices without inconvenience. If you have a phone and a laptop, do you have enough storage for a full copy of everything? If not, you need to add a third computer, deal with external drives, etc. One appeal of cloud services for many people is that you can save your data without needing to have enough space to have a full local copy and still be able to access it.
> > secure them
> And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.
Again, this is a comparison question. A service has a separate security trust boundary so someone who compromises your account doesn't get infrastructure-level access and cannot permanently delete things without you having a chance to recover. If you're doing it yourself, you're taking on that responsibility entirely yourself. Maybe you're confident with that, maybe you're not but it's something that you absolutely have to think about for a data storage system.
> > have a backup plan
> Another non-sequitur. Either tool can be part of a backup solution.
You might want to check the definition of non-sequitur – it's not a get-out-of-jail-free card for avoiding an answer. Just to reiterate, ask what happens if your hard drive starts corrupting blocks, someone steals your computer, your house burns down, you get malware which encrypts every file on your computer, etc. With Dropbox the answer is “I buy a new computer and restore my data. Since the malware couldn't overwrite the older copies, I lost nothing”. If you're self-hosting, that could have the same answer but it requires more skills and ongoing commitment to do things like off-site backups.
What I've found to be sadly common is that people do these comparisons without actually matching equivalent levels of service and then get a painful educational lesson when something goes wrong and they lose something they cared about.
Again, this is false. The P2P relay/discovery nodes are operated by third parties donating server time and bandwidth. The user is not required to operate those parts of the network.
> That's an unrelated topic.
Definitely related to storage provisioning.
> This is about the total size of your data and whether it fits on multiple devices without inconvenience.
Convenience is entirely dependent upon the user's requirements. As I said, each node is not required to maintain full replication.
> you can save your data without needing to have enough space to have a full local copy
I'm not sure that putting a significant fraction of one's proverbial eggs in one basket is a selling point.
> If you're doing it yourself, you're taking on that responsibility entirely yourself.
I would add that you're always responsible for your data, third parties or not.
> What I've found to be sadly common is that people do these comparisons without actually matching equivalent levels of service and then get a painful educational lesson when something goes wrong and they lose something they cared about.
You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.
Okay, let's think about this a bit more in depth: who's operating the computer which stores the data? If I have a laptop and a desktop, can my laptop backup its data if my desktop is powered off or my cable modem is down? If those third-parties decide to stop donating their time or something breaks and they don't have time to fix it, does my data still sync?
I don't see how the answers to any of those questions are compatible with “this is false” being a correct statement.
> You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.
… and that's why for most people it makes sense to outsource these tasks to professionals who specialize in that work, just as most people pay mechanics to work on cars and contractors to fix their houses.
Again, my point was not that syncthing is bad but that an open-source project is not the same thing as a supported service. I get that you like this and want to evangelize it but misrepresenting what it does is just asking for someone to be disappointed.
I’ve seen many other services have major issues syncing files... dealing with conflicts, corruption, random file types like issues around Mac resource forks and file-folder types, etc. I’ve seen weeks of work get lost because gdrive stopped syncing, then when resuming overwrote all of a colleagues updated files.
Dropbox has solved all such problems.. in part because they’be been around forever, but also because they’ve hired great talent to do nothing but sync. I trust them way more on that core competency.
If you look at the filename on the linux download is says 2015 in the filename. Has the linux client gone untouched for 3 years?
Dropbox is violating their philosophy as a universal solution and squandering their key selling point for some small cost savings. What a horrible decision.
Time for some of us to start work on adding extended attributes to more filesystems?
Source: Using XFS at work for OpenStack Swift, which makes extensive use of xattrs and thus prefers to run on XFS.
So, if other programs follow suit, will we start seeing options to lie about the filesystem type?
Right now it just links to the second page of the discussion; the community moderator's message is on the first page.
The sync client has worked flawelessly for me so far. Plus you get CalDAV/CardDAV right out of the box.
Experienced users run plethora of filesystems which support the needs of dropbox.
IMHO, this is a lazy solution to a relatively simple problem.
I'm an architect for a Dropbox competitor. Sometimes we need to draw a line in the sand for what we support, and what we don't support. This is mostly due to balancing cost / benefit. A customer may do something strange that we don't support, and we have to weigh how many engineering resources it will take to support the customer. This can apply to unusual filesystems that we don't actively test our product with.
IMO, Dropbox did the right thing. It's only real technical users who get into different kinds of filesystems; and these are the same kind of users who can understand, "Dropbox only works on X, Y, and Z."
a- FS is something we support, great! Go on...
b- FS is an unsupported one, so run the tests and if they pass warn the user: "Hey! We don't support this, but it looks like working. If it fails we can not support you. Are you sure? (Y/N)"
c- FS is an unsupported one, so run the tests and if they fail tell the user: "Hey! We can not work on this FS, sorry.".
The good thing is you implement the tests once. Since, POSIX standard is a standard, so run the tests over that interface. You practically don't need to maintain anything about the tests. Maybe run a couple of unit tests over a simulated environment, that's all.
If you are going to pay for something, Insync and Google Drive make a decent Dropbox alternative. I'll be honest, though, I simply stopped using syncing solutions like these, so I really don't know if there are now better options across platforms.
Btw: Resilio Sync used to be known as BitTorrent Sync.
Their focus seems to be on cost cutting and better value extraction than growth and features these days.
Dropbox tells with a very unhelpful popup: "Move Dropbox location - Dropbox will stop syncing in November".
And on the forums, dropboxer Jay precises that starting Nov. 7, 2018, they're limiting support to Windows / NTFS, macOS / HFS+ & APFS, linux/Ext4. They say missing X-attrs support is what guides dropping other fs.
They didn't answer yet if displaying this message to users of common-through-Ubuntu Ext4+ecryptfs is intentional.
Colin is the founder, and also a HN celebrity because of this comment (which he regrets, but never gets old):
And then how does that compare on macOS where there's JHFS+/HFSX and APFS?
So, why would one pay?
Think nerd friendly and minimal, like NearlyFreeSpeech is to domain registrars
EDIT: Found it.