Hacker News new | comments | show | ask | jobs | submit login
Ending support for Dropbox syncing to drives with certain uncommon file systems (dropboxforum.com)
394 points by ronjouch 46 days ago | hide | past | web | favorite | 416 comments



It's not encrypted ext4, it's ecryptfs (which acts as a separate layer entirely, creating a virtual encrypted filesystem on top of ext4) - probably doesn't support some inotify feature or some extended attributes that aren't set correctly when used through ecryptfs.

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.


Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it.

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.


On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.


Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base...

> "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."


There was also a series of issues found by with the encryption used by ecryptfs:

https://defuse.ca/audits/ecryptfs.htm

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.


Author of eCryptfs and EXT4 encryption chiming in.

"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.


Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings.

https://defuse.ca/audits/encfs.htm

I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.


According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption:

"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."

[1] https://www.linkedin.com/in/michael-halcrow-1880601


There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.


On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.


For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes.

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.


They could not have done that to the bootloader because of SecureBoot.


With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem.

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.


You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk.

This would certainly be more work to set up than vanilla full-disk encryption, though.


Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.


> Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

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.


Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password


That's fantastic to know, thank you. Do you know if it's complicated to set up?


Though unfortunately if you want to dual-boot, you have to manually set up the encryption :/ As in https://askubuntu.com/a/293029/25639 – I do wish the installer could do that instead of asking dual-booters to compromise.


If it just renewed and this changes breaks your use case you can probably request a refund since your system is no longer supported.


What issues have you found with this Onedrive client[1]? I've been using it for over a year without any hiccups beyond the odd duplicate file

[1] https://skilion.github.io/onedrive/


I second this. I created my own systemd service so it runs when I’m not logged in and it’s been as reliable as Dropbox. On the one occasion (in 3 years) it did screw up, I simply ended up with two copies of the same file.


I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.


Out of curiosity, what happens if you office subscription ends? Obviously you won't be able to sync but does onedrive have some sort of grace period to let you download your stuff and at what point would it go and completely delete your data?


If it's the business version, you have full access for 30 days, admins have access for 90 days, then it's deprovisioned (source: https://support.office.com/en-us/article/What-happens-to-my-...)

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...)


I believe the modus operandi for most personal cloud storage providers here is to make the entire dataset read- and delete-only until the user gets enough storage space (by upgrading or deleting files) to be able to write/upload again. That, plus some incessant push messages to your client devices about upgrading, which is annoying but expected.


Office stops working if your subscription ends so most likely they will renew their subscription.


Use a flow to replicate your onedrive in Azure Files, then mount it to your Linux box: https://flow.microsoft.com/en-us/galleries/public/templates/... AND https://docs.microsoft.com/en-us/azure/storage/files/storage...


That would be very much not free


rclone mount


I use Google drive, but the Linux support was awful and I started using insync. It's about $25 for a lifetime license and I love it. I run Ubuntu with encrypted home and have for years. It works great and I highly recommend it, and I don't work there, just a happy user. The Nautilus integration is decent too.


Not trying to rain on your parade, I hope it fills your use case.

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.


Not sure what your exact role is but is there a possibility to move this client from insync to rclone?

rclone is rsync for cloud storage services -- https://rclone.org/


I seldom use it, so I can't say how well it runs, but from Gnome version 3.22 if I'm not wrong, Google drive is integrated with Nautilus (the file manager) via GVfs/GIO and the couple of times I used it to share a file worked flawlessly.

YMMV ^__^;


You could use Nextcloud instead.


I recently switched to Nextcloud because Dropbox's Android app is terrible, and like it a lot. It does everything Dropbox does, I get as much space as my server has, and the apps are all better than Dropbox.

I also use Syncthing, which I am very impressed by, it works really well.


Security concerns aside, I found home directory encryption to have awful performance. It also caused issues with file name length.


If you feel comfortable with Google, Gdrive has a great client in the form of OverGrive.


And there’s always rclone. Combine that with whatever encryption you want and you’re set.


Just put /home on a separate partition and please the BOFH gods.


I'm surprised to hear anyone is still mounting home and root on the same partition, frankly. It's made my life sooo much easier since I started doing it ages ago.


The (supposed) Dropbox engineer refers to Extended Attributes.

Maybe they’re doing uncommon stuff with ’em that uncommon filesystems cannot cope with... ;)


> "It's not encrypted ext4, it's ecryptfs (which acts as a separate layer entirely, creating a virtual encrypted filesystem on top of ext4) - probably doesn't support some inotify feature or some extended attributes that aren't set correctly when used through ecryptfs."

Thanks, I updated the title.


What do you think are the chances that Dropbox “just works” on a file system on which it isn’t regularly tested but which nominally has the right feature set? I’d go with “not good”. :-)


This whole article read (to me!) as them wanting to reduce test load, and probably workarounds in their codebase.


The backing files for your ecryptfs will still get synced though, correct?


If you point it at the backing files and they're stored on a supported FS, I see no reason why they wouldn't.


For those interested in open source alternatives, syncthing, NextCloud (fork of ownCloud), and Seafile are some of the big names in this space, as others have mentioned. Personally I'm on syncthing. It's one of the best pieces of software I've ever used. My only complaint is it's not really instantaneous for me. In theory it works with inotify, but I've never quite been able to get it to work. I'm confident it will eventually, though. It's a fairly new feature if I'm not mistaken. For now, if I really just need to get a file from point A to point B right now, I used File Pizza.


I'd definitely throw Keybase in there as well. To me it has the easiest experience being cross platform, integrated with the filesystem, end-to-end encrypted, and having solved the identity proof piece.


Keybase is nice, but it isn't a Dropbox replacement. Your files aren't accessible offline; that's kind of a core part of a file sync instead of a file store.


I take your point that they use different mechanisms to provide access to files which are not fully interchangeable. With that said, I think many people probably don't really care or have a need for offline access, since nowadays people almost always have connectivity. Given this I would say in many (maybe most?) instances Keybase could replace Dropbox in practice.

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.


> I take your point that they use different mechanisms to provide access to files which are not fully interchangeable. With that said, I think many people probably don't really care or have a need for offline access, since nowadays people almost always have connectivity. Given this I would say in many (maybe most?) instances Keybase could replace Dropbox in practice.

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.


Really? If you lose access to your dotfiles and OneNote notebooks for 5 or 10 minutes (that would be one long tunnel) that's completely unacceptable? This also sounds like a daily commute that could have easily been planned around if that time is really that important. Besides, when I work with Keybase I copy the files to my machine ahead of time to a local directory, so I likely would never notice such a drop in connectivity.

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.


When OneNote freaks out because it can't access its drive during an auto-save and hard-locks? When zsh can't start because it can't find files sourced in .zshrc? Yeah, that's kind of important and that should nev-er happen.

"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.


You use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly.

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 use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly.

You may be misunderstanding intent.

Consider https://keybase.io/blog/encrypted-git-for-everyone


I don't think so. The encrypted git functionality in Keybase operates differently from kbfs. AFAIK the encrypted git ability just functions as a git remote helper that doesn't use the local kbfs mount on your system, so you wouldn't run into the same situation as say a file you are copying to your private keybase folder.

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.


Airplanes are a common case where people have long stretches without connectivity, either due to not paying for wifi or any if the other reasons it might be unavailable or unusable.

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.


Agreed, but these are planned events where you won't have connectivity, so you can copy the files to a local folder prior to the trip. I recognize that might not be as convenient as having the system perform a push to your machine to sync it. I think in those cases I'd probably just run rsync against the keybase folder.


I know that in a day where I have to produce a live show, write a raft of code, negotiate a new job offer, and take my dog to the vet, I want to remember to copy files to a local folder.

No, wait.

I want my computer to do scutwork for me instead because that's its job.


Planned events in one sense, but routine daily life for those in NYC, or unplanned events in cases where airplanes unexpectedly lose WiFi. Among other examples.

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.


Offtopic but Africa is not a country.


Good point. I realized at the time that it wasn't quite right, but didn't figure out how to fix it. I should have written "those in Africa," or even "most of those in Africa."

Sorry for letting a rushed comment perpetuate the common Western stereotype of conflating all of Africa as if one single thing.


Syncthing is a great piece of software. I configured it on three of my machines in March and I've had zero issues since. In fact, it has worked so well that I don't even think about it.

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.


There's a (closed source?) iOS client: fsync


Is Syncthing here to stay or will it morph into a nextcloud or a btsync or that ubuntu thing or be abandonner in 6 months ?


My impression is it's here to stay. I think I've been using it for about 2 years now. The protocol is completely open as well.


Cool, are there third-party apps beside the official ones ? That would be a strong indicator.


I've been meaning to try git-annex as well. Anyone have any experience/opinions on it?


I used to use ownCloud. Just curious - why is it not in your list of alternatives? Did the project die?


Nextcloud is a fork of Owncloud that's led by the original Owncloud developer, and it seems to be more popular with the free software and Linux community. It looks like both are still active.


Nextcloud is the successor of ownCloud.


I'm still running OwnCloud. I've tried twice to move to nextcloud but run into syncing issues from my clients with the same data (and same basic setup) that Owncloud is currently handling fine.

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.


I haven't run it, but previous HN threads often have comments of ownCloud randomly deleting files, along with other weird bugs.


Owncloud still exists, but most original developers moved to its fork Nextcloud.


If you just want to get a file or files from A to B you can use rsync. It works great (although I don't know if it works on Windows)


rsync is a great tool, but I'm talking about cases involving NATs and smartphones (although I'm sure there's a reasonable android version of rsync available).


The kicker is in the couching - dropping support for "uncommon filesystems" - of which their definition includes the default filesystem used by the most popular distro. Just dumb or wilfully ignorant?


I'd bet that by Dropbox's user metrics "the most popular distro" still qualifies as "uncommon" for a Dropbox client. Despite being the year of desktop Linux, non-server Linux boxes are comparatively rare.

That said, Ext4 is still supported, just not with encryption.


According to shittyadmin, it's not even encryption it's encryption with ecryptfs.


No stacked encryption on top of ext4. LUKS+ext4 should still work (since it's visible to Dropbox as just ext4 with cryptsetup/LUKS handling the underling container).


> 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.


Honest question, what do you believe is "the most popular distro"? Professionally, I have never seen a BTRFS deployment, nor any of the distros commonly at the top of Distrowatch (Manjaro, Mint, Elementary...).

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.


Ubuntu uses ext4 and the default is to ecryptfs the user's homedir.

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.


I'd argue that the normal thing to do in the Ubuntu installer is full disk encryption, rather than homedir encryption.

Both are checkboxes, though, so one could select whichever they wanted. Full disk encryption is the most sensible one, though (better evil maid protection).


Encryption is opt-in, not the default.


It's not even opt-in on Bionic anymore (at least, that checkbox is gone from the installer where you enter your user info)


I'm pretty sure home-dir encryption was the default with Ubutunu 15.04.

I know that I installed Ubuntu with default settings, and was pleasantly surprised by that. Not sure about the exact version though.


I don't think it was the default. There was an "encrypt my home dir" checkbox which was unchecked by default.


I would never attempt to use btrfs again in any environment. But if it is used, I hope the person has extremely strong backup policies in place for when it eventually crashes.


I've used it for the past 4 years as my primary development machine. Never once had an issue. However, I used Arch Linux, which always has newer kernels. I know there have been some bugs on other distros which run older kernels.


I ran it for quite a while, 4 terabytes lost specifically due to btrfs, I will never trust it again.

I've heard several admins flat out scoff at the idea of using it.

Make sure you have backups with a reliable fs.


Fair point - I'd be fairly confident that it's Ubuntu at least on the desktop, based on experience the data I've glanced at previously. But I could be mistaken.


What I am confused by is what they think will happen to revenue.

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.


Step 2: use the 20% developer manpower required to support filesystems used by 2% of the userbase to instead better support the other 98%.


Step 3: $13b company cries over $1000/yr loss of revenue.


This type of snarky dismissal gets pretty old.


What really gets old is seeing:

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.


Not as old as someone publishing a blog with the title "This is the year of Desktop Linux".

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.


Of course my example is essentially irrelevant in isolation. But you do should understand that Dropbox is different than their competitors. Dropbox are the only ones who support Linux. Google Drive, Box, OneDrive etc do not support Linux (random partial featured third party clients do not count.)

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.


I'm going to make the argument that Dropbox doesn't support Windows, because they don't support FAT32. That's just as true as your argument that they don't support Linux, because they very much do still support Linux.


You can't install Windows on FAT32. I'm pretty sure your home directory (where the Dropbox folder is) can't be on FAT32 either. About the only thing that uses FAT32 are USB sticks smaller than 32GB. It is extremely unlikely anyone would want to run Dropbox on a FAT32 volume, and I suspect it has never worked due to the filesystem limitations. ie you would have to struggle to end up in this situation as a Windows user. And even if you did, I doubt any of their competition supports FAT32 either.

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.


I do want to clarify that FAT32 can be up to 2TB (or more if you push up the cluster size). Microsoft just decided they wanted to be pushy in their formatting tool.


Running Linux without encrypting the drive is a big security risk. Anyone who can get their hands on the machine has full read and write access to the hard drive by booting with a thumb drive. Any company that uses Dropbox for Business and has employees who use Linux will be putting a security hole in their business if they decrypt their hard drives in order to use Dropbox. (Possibly including Dropbox, if any of their employees use Linux.)


Maybe they mean uncommon amongst their userbase.


> the default filesystem used by the most popular distro.

Ubuntu doesn't use ecryptfs (or even support it afaik) by default.


Let's not forget Fedora or EL users, XFS has been the default for some time now in both.


Only Fedora Server. Fedora Workstation, Cloud, Atomic, and all the spins, are using ext4 on LVM.


However, Fedora Workstation is strongly considering moving to XFS, as are several of the other editions.


I was under the impression that xfs was the default file system on recent versions of Redhat / Centos that's got to be a large share of the corporate Linux market.


compare that with all their Windows and OSX user base, I guess it is less common filesystems.


Your two choices unnecessarily rule out a third: that Dropbox client phones home what filesystem is in use, and so they have concrete data backing their assertion.


I basically only use Dropbox because it is supported on Linux. Also its syncing technology is sooo much better than Google Drive you would think Drive was built by interns. However, they are taking their sweet time with newer features like Smart Sync. It's disappointing because I'm paying for these features and yet they're not supported on one of the platforms my whole company uses. All in all I really hope Dropbox doesn't keep chipping away at Linux - I fought hard internally to use it and I don't want to be proven wrong.


There's a decent open source sync daemon for OneDrive on Linux - I'm the packager who looks after it on Fedora. With the odd exception when APIs change it just works.


OneDrive doesn't support dotfiles and thus can't sync Git repos.


OneDrive doesn't support dotfiles and thus can't sync Git repos.

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.


I think you can do that in explorer if you change some of the options.


Err... I can’t imagine a scenario where one would want to use OneDrive/Dropbox to sync git repositories. It’s like having your local Dropbox folder inside your local OneDrive folder — only a lot worse.


I keep my .tex, .md, and .org files under source control, but I don't bother syncing to GitHub. I just back them up with the rest of my personal (non-code) files.


Personally I sync my git repos with git, everything else with OneDrive - that said dotfile support could be added to the client at least in theory…


Onedrive handles Git repos on Windows fine. It does balk sometimes if you feed it large repos, but most often it works fine.


This just sounds like a horrible scary idea. What happens if I change something in a repo on multiple machines - a OneDrive merge conflict inside .git sounds like a nightmare.


I hadn't thought of that, that indeed sounds torturous!


What daemon is that?


https://github.com/abraunegg/onedrive (currently I package the original project by @skillion, but this fork is better maintained...)


It appears this might be related to dropbox (mis)using statfs's f_fsid field as part of its authentication system. The dropbox devs apparently assumed that this field was stable, but on XFS (for instance) it can change.

dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...


That sounds to me like the most likely hypothesis in this thread.

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.


Oof, although not surprising.

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.


Sometimes it's not about assuming something is stable, but rather finding a workaround you need and hoping it lasts.


Another alternative is nextcloud... It also has a sync desktop client and works great in my company for sharing folders with colleagues or keep business documents in sync on desktop and laptop.

There are even third parties that install it and manage it for you.

[1] https://nextcloud.com/


Seeing how an encrypted home directory is as good as the default option in Ubuntu, and seeing as it already works now, this seems like a dumb move.

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.


Not in the latest Ubuntu installs. They do FDE instead of home folder encryption.


Because LUKS > encryptfs, even though Dustin Kirkland has done absolutely fantastic work on encryptfs.


The option to encrypt your home folder is still there in Ubuntu 18.04 (which I set up only yesterday), and appears after you set up volumes upon initial user creation.

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).


I just spun up an 18.04.1 install in a VM to check, and I don't see an option to encrypt the user's homedir during installation.

Edit: It's listed under "Other base system changes since 16.04 LTS" https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes


IIRC it does show if you use the advanced installer option (ie where you go manually through all steps).

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.


You can manually encrypt your home folder after install, and perhaps they re-enabled the option to do it automatically in 18.04.1 but I haven't read that. It was definitely not there in 18.04.


Excluding XFS is an odd choice as it's very common in the server world.

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?


I would hold my horses on xfs being unsupported claim. They explicitly said any modern file system with xattr is supported. XFS does fit that description. OP has drawn his own conclusions from the Dropbox reply.


The HN link is pg 2 of the forum thread; on page 1 a Dropbox employee states the following:

>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)[1]

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.

[1]https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...

Edit: added link to the proper comment in the Dropbox thread


They did not explicitly say they support "any modern filesystem with xattr". They said that they support EXT4 and nothing else on Linux.


My /home is XFS on my Arch system and I received the same popup from the Dropbox client. I can confirm that this does apply to XFS as well.


Same for Btrfs


It's the default filesystem on RedHat, CentOS and Fedora. Looks like they will be dropping that.


They probably don’t have a lot of users who install and use the Dropbox client on a server machine.


Ugh, I use Dropbox on several platforms, some NTFS, some APFS, some HFS and exFAT. The majority of my files are synced to exFAT because it's the only bloody filesystem that's officially supported across all major OS. No it doesn't support extended attributes and I don't care, 95% of my files are photos!

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.)


As a developer I understand that each supported filesystem adds development workload and potential for bugs and at some point you need to weigh this cost against the benefit. The problem with this is that the people who use these filesystem are more likely to be opinion makers for other people in the choice of file syncing solution. Dropbox is big enough so they think they do not have to worry about it. But there is a real possibility that they will alienate just enough influential people, that this will erode their user base more than they realize.


This is exactly why I stopped using Dropbox and moved everything I have to my own https://nextcloud.com instance. It's very easy to install and upgrade, it is stable, have way more features than Dropbox and you have total control over your own data. Overall a superior experience. If they would do something I don't like, I would just never upgrade anymore and be done with it or just copy the files out of the /data/Nextcloud folder and move to another one open solution.


I set up a little Ubuntu Core server with Nextcloud for archives and sharing, and Syncthing for slightly cleverer sync of files I'm actively working with. Syncthing is decentralized, and it's designed so you can just pick any folder and sync it between your devices, which makes for a really handy workflow. But I like good having a long-running server in the middle that I can treat as canonical. That way I have one place for backups, my devices can sync with the server over the Internet when they don't have each other, and I can access Syncthing files via Nextcloud.

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.


This echoes my experience exactly. I use Syncthing for all the documents I don't need a web UI for or that I don't need accessible on mobile (only between computers), such as my ebooks, PDFs, things like that, and Nextcloud for everything else.


"If they would do something I don't like, I would just never upgrade anymore and be done with it." -- That sounds like a good strategy but in my experience, it never works because your technology environment is not a vacuum (I assume). At some point you'll need an upgrade for security, compatibility, etc.


It can run in a container, a virtual machine, hosted on a cloud instance or whatever. Nowadays, you have infinite choices for isolation. One of my colleague runs it in a DigitalOcean droplet and nothing else.


A quiet media server at home and VPN is what does it for me. That solution is not for everyone but someone could start making pre-built images or media servers with nextcloud. I believe FreeNAS and the like already have nextcloud as an app option.


If you want to run your file sync client in a container, I think that limitation alone removes a huge amount of value from a low-friction file sync tool.


Why would you run the client in a container? I was talking about the server.


Because the client can be just as vulnerable to security issues as the server is.


Isolating for security is a totally different topic. We talked about pinning the application to a specific version, and I suggested that it can be done with various tools, isolating from a bigger operating system where packages would automatically updated and Nextcloud would break after a while. It has nothing to do with security.

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.


> but there are tools to secure an outdated app in other ways either.

Not really.


I switched to nextcloud a while ago. When Dropbox started sending me email after email telling me they were going to delete my account soon, I couldn't wait for it to happen. (OK, I could wait since I wasn't willing to spend time to log in and do it myself).

It is nice to know where my data is.


An easier option at the moment is probably SyncThing which just syncs directly between your devices. I use it for sending my KeePass DB and photos from my phone to my NAS.

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.


nextcloud is fine, but I have a multi-function printer with scan-to-cloud support (very insecure, but VERY useful and super easy) that support only dropbox, box, microsoft amd google. I'll try rclone :-)


Dropbox isn't even the cheapest or best file syncing service, they're basically all a commodity at this point and if they don't want you as customers... just go elsewhere.


Would you kindly provide recommendations? I'm looking for a sync service which can run on windows AND linux (which is why onedrive and google drive are out)...and i'm willing to pay a fair monthly fee.


rsync.net seems to get mentioned around here every now and again. I haven't used them though personally, so not sure of good/bad/etc.

Unlike what their name (rsync) suggests, they do seem to support Windows clients and aren't *nix only:

https://www.rsync.net/resources/howto/windows.html


The documentation for the Windows client (1) almost seems like a joke. In the screenshots the text gets cut off in the UI, there's sentences that say "don't use this versioning feature we're about to talk about" and tons of text that's been striked-through. There's also zero mention if the client supports backing up open files via volume shadow snapshots which is basically requirement number one for any Windows backup client.

1 - https://www.rsync.net/resources/howto/windows_backup_agent.h...


We're really all about the direct unix to unix connection.

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.


Same here, I had heard rsync.net mentioned previously...HOWEVER, i did NOT know they had a windows client. Thanks!


I had a pretty underwhelming experience with rsync.net and their cheaper version without snapshots a year ago. Speeds where initially 1MB/s on a gigabit connection between Sweden and their Switzerland location. After complaining they exempted me from traffic shaping and I got 2-4MB/s instead.


I know who you are and I am sorry to hear about this (again).

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.


Nice to hear that my experience was the exception and not the rule! I'm pretty happy with my current solution combining a cheap VPS in the Netherlands for the "I need a server to put some files on" usecase and (encrypted) backups to Backblaze B2, but I'll keep it in mind if I ever need some storage in the US :)


I would recommend Syncthing. Fully open source. It is however self-hosted. But they have clients for basically everything, including mobile phones.


It doesn't support symbolic links at all, deal breaker for me. I can't afford to start duplicating content just because it can't follow a symlink.


Have you tried hard links?


I used to run syncthing...but about 1 year ago (when i started with current employer) they blocked it. i forgot what port it uses, but my employer gave me the ol' wag of the finger for "using an unauthorized app". Funny how dropbox was not blocked but syncthing was.


Welcome to the world where everything except 80/443 is blocked. Sucks but you can still make things work.


Just use syncthing. It works better, is open source, and runs on everything.


I guess you could say it runs of everything unless you use one of the two most popular operating systems in the world: Android and iOS.


Not sure what you're on about, its right in F-Droid [1]. What is or isn't on iOS is in Apple's control. I recommend to take a look at Nextcloud. You can use it to control your own files, calendar, etc without some third party using it for data mining.

[1] https://staging.f-droid.org/search?q=syncthing&lang=en


There's syncthing for Android: https://github.com/syncthing/syncthing-android


Only recently started playing with SyncThing (about the time SpiderOak's warrant canary expired).

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).


Whoops, the website could make that more clear. "Works on Mac OS X, Windows, Linux, FreeBSD, Solaris and OpenBSD."


It runs very well on android with termux.

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.


Doesn't that require you to play sysadmin running your own servers?


No. There's already a peer-to-peer relay infrastructure in place for when your devices can't make direct connections to each other.


That sounds like the answer is actually yes because you have to run the various computers, provision enough storage to hold everything, secure them, and make sure you have a backup plan.


> run the various computers

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.


> > run the various computers > > Are you saying dropbox works without computers O_o?

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.


> run the various computers

That's a vague assertion that can apply to anything.

> provision enough storage to hold everything

Syncthing can ignore directories/patterns at the local level.

> 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.

> have a backup plan

Another non-sequitur. Either tool can be part of a backup solution.


> > run the various computers > > That's a vague assertion that can apply to anything.

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.


> with syncthing, you need to operate every piece of the system.

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.


> > with syncthing, you need to operate every piece of the system. > > 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.

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.


If you want absolute feature parity with dropbox, then yes I suppose you do. But you don't have to stand up a server just to sync files between your devices.


syncthing is p2p, you just run it on the devices that you want to sync with


What about Adrive? They don't have Linux client, but they support WebDAV, rsync, (S)FTP(S). I guess, getting some pretty stable client for these protocols won't be a challange.


Why do you say it isn’t the best?


I was gonna suggest onedrive but realized they don't have a linux client. Honestly for linux, dropbox might be your best bet...


What makes you say onedrive is better than Dropbox?


Because of its close integration with Office 365, and it's cheaper.


You said it wasn’t the best file syncing... office 365 integration doesn’t seem to suggest that one drive is a better file syncer... especially because Microsoft owns office. I’d expect that. Gdrive does Gsuite integration, but I wouldn’t knock other services for not having that.

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.


I continue to wonder about Dropbox's support for Linux. It's been the primary reason that I use them so heavily and recommend them so often.

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?


This is a tragic decision on Dropbox's part. The service's popularity is a product of it being stable and running everywhere. If they start pulling back compatibility, where does it end? Even if this change only impacts a small percentage of users, it threatens everyone that their compatibility may be revoked.

Dropbox is violating their philosophy as a universal solution and squandering their key selling point for some small cost savings. What a horrible decision.


Their reasoning of "you need a filesystem which supports extended attributes" sounds legit.

Time for some of us to start work on adding extended attributes to more filesystems?


I believe all 3 filesystems have support for extended attributes, so it doesn't seem legit.


XFS is well-known for its extremely good xattrs support, so that does not add up.

Source: Using XFS at work for OpenStack Swift, which makes extensive use of xattrs and thus prefers to run on XFS.


This seems like the equivalent of user-agent sniffing. So even though the problem is a feature (xattrs), they will try to detect whether or not the filesystem is ext4 and stop syncing otherwise? Is that correct?

So, if other programs follow suit, will we start seeing options to lie about the filesystem type?


This should probably link directly to the message from the community moderator: https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...

Right now it just links to the second page of the discussion; the community moderator's message is on the first page.


Self-hosted Nextcloud instance + AWS for storage puts you somewhere around $10 to $20 per month depending on how much space you need. Just throwing it out there.

The sync client has worked flawelessly for me so far. Plus you get CalDAV/CardDAV right out of the box.


Well I for one will be taking the $0 per month that I spend on their free tier elsewhere


This makes no sense. For example, XFS is a very robust and actively developed filesystem and is now the default on many distros. It also supports xattr.


Why not run a small set of tests after installing and see whether the required set of FS features available?

Experienced users run plethora of filesystems which support the needs of dropbox.

IMHO, this is a lazy solution to a relatively simple problem.


Most likely Dropbox needs to set these limits so that they can allocate their quality assurance department to very thoroughly test what they claim they support.

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."


From a QA point you're actually right. I don't think Dropbox needs to support all filesystems, but as a programmer and and advocate of better user experience, I'd like to see a system which behaves a little differently:

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.


I wonder if I'll get a prorated refund for the time I pre-paid. This is really silly of them, the entire reason to use dropbox is because they have a client for everything.


Seems ludicrous when XFS is the default file system for RHEL.


Yep. Dropbox is going to lose some customers. Maybe it won't be too many (compared to Windows/Mac), but the customers they will lose will be their most technical.


How many customers do you think are running RHEL as a desktop workstation and allowed to use Dropbox?


If any, I bet they can be counted on one hand.


Syncthing will do the job. Yes, it doesn't implement a cloud store like Dropbox. You have a couple of alternatives: 1) get a cheap vps host (digitalocean, vultr, etc.) and make it part of your syncthing 'cluster'. 2) get a raspberry-pi running syncthing and a big external HD and put that somewhere else (parent's, brother's, office, etc.).


I gave up on Dropbox. Linux was always a second class citizen, and it only ever seems to get worse.

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.


Is there any good alternative that has Linux support and isn't Google Drive? And supports shared folders?


Nextcloud


Seafile.


I have been using Resilio Sync on Linux, Mac, Windows, iOS, and Android, and it works a charm for me. In case this turns out to be a problem for you, maybe give them a try. Never an issue on Linux with Resilio Sync. I run a copy on my VPS in the cloud for remote storage.


I'm about to cancel my Dropbox subscription and move to Resilio, so I wanted to chime in and say I've had a great experience with Resilio in the past and my friends are also using it with great results.

Btw: Resilio Sync used to be known as BitTorrent Sync.


Ecryptfa is the default for new Ubuntu installs, isn’t it? They might have well just come out and say they were dropping Linux support going forward instead of dance around it.

Their focus seems to be on cost cutting and better value extraction than growth and features these days.


Could people whose filesystem will no longer be supported work around this by making an ext4 filesystem in a file and mounting that file via the loop device, and moving their Dropbox directory to that?


Yes, but it's kinda ugly for regular Joe user. You'll have to know how to manage it: fragmentation, setting initial size and resizing, trimming, how to automate activating and mounting it. Etc.


TL;DR:

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.


Missing xattrs? What?


See original message from Dropbox support: https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...


That's cool dropbox, us Linux users prefer services like tarsnap anyways: http://www.tarsnap.com/

Colin is the founder, and also a HN celebrity because of this comment (which he regrets, but never gets old):

https://news.ycombinator.com/item?id=35079


As much as I like tarsnap, comparing it Dropbox makes no sense at all. They do completely different things.


For people looking to move to a service that supports Linux as a first class citizen: Mega works well enough as far as syncing files goes.


I had used Mega since it was introduced, and I had recommended it before with its generous 50GB free space and Linux support. However, Mega had become unreliable about a year ago, when it started to delete files after bad syncs. Be very careful about putting important files. Also sometimes, upload speed is very slow (took me over a minute to upload 120k file) and the sync on the iOS became really bad - it always get stuck on "Downloading...", but fails to sync. I hope they fix the problems, but until then, I've decided not to use it.


Aside from the performance hit, can’t users of other file systems just add a loop back device and mount that for Dropbox?


I wonder if the xattr issue has anything to do with there being adequate abstraction of underlying file systems by the VFS? Btrfs, ext4, and XFS all support xattr, but I don't know if they all support xattr the same way via a single interface?

And then how does that compare on macOS where there's JHFS+/HFSX and APFS?


Its too bad there isn't a standard for Dropbox-like functionally yet. An RFC that everyone can write to.


Technically there is WebDAV. Yeah I know, but it's there and it's a spec. Another de-facto spec is rsync, iirc tarsnap was basically built on that. At some point there might have been even a business or two that offered rsync access.


Commercial rsync... https://rsync.net/


You might be thinking of Duplicity -- it's based on rsync. Tarsnap works in a very different way.


Is this a new business opportunity?


Probably not as such users are just a vocal minority, and probably not enough to use as a consumer group.


And they really hate paying for stuff. Doubly so for things they think are simple and can be done "by myself".


And you wonder why if this is what they get when they pay.


You get to either pay to be a second class citizen at some place controlled by somebody else, or invest a few hours into getting a solution tailored to your use-case that won't bring bad surprises.

So, why would one pay?


Doesn’t mean the niche user base isn’t big enough to support a small scale operation

Think nerd friendly and minimal, like NearlyFreeSpeech is to domain registrars


Good example of a small scale niche service that seems to do well (I think): https://www.tarsnap.com/


Those little already have syncthing for sync and borg/duplicity systems for backup. (With a backend of choice) Why would they use a service that locks then in to one provider?


Same reason they use Dropbox: they don’t want to manage all that


So, what's the reason? I can't see it on the linked page. I would have thought that dropbox functionality is totally filesystem independent. I can't think of a reason why they'd do this.

EDIT: Found it.

More

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: