Dropbox drops support for Linux. What alternatives do we have?

[TheFu]

Sync with android not reallly an issue as space is limited on my android phone. I'm at almost my 50gig limit, so I would have to sync selectively. Mega's android app however makes my files available - I can see and download them, but they do not sync

This is Paddy's thread, but nextcloud allows you to control which files/directories are sync'd on each device. The amount of storage available is unlimited, since you host it. 50G, 500G, 5TB, 50TB .. how much storage is completely up to you.

If you use a VPN for access when remote, then what is hosted is generally secure. And it effectively prevents anyone in the world from even attempting brute force password access to the login page.

[Paddy Landau]

Thank you for all the comments and ideas.

I've found that pCloud suits my purposes best; it seems to do everything that Dropbox does, except that it supports Linux fully.

The one downside is that pCloud doesn't have a PPA.

[Frogs Hair]

Thank you for all the comments and ideas.

I've found that pCloud suits my purposes best; it seems to do everything that Dropbox does, except that it supports Linux fully.

The one downside is that pCloud doesn't have a PPA.

Looks like a good alternative.

[Geoffrey_Arndt]

So, just to be clear, I run Ubuntu 16.04 on a 120GiB SSD using the ext4 file system. About two-thirds of my files are not sensitive (and are not ecrypted). The other third are (or are border-line). For those I prep them for Dropbox via encrypting using 7z AES encryption (which is very fast and can handle full directories as well as individual files).

Is Dropbox saying those files encrypted with 7zip compression (AES) will not be accepted for storage . . . . ?

[TheFu]

You'll need to read what Dropbox said and decide. But do you really want to use services from a company with that behavior? Your choice.

I have brute forced passwords in ZIP files many times over the decades. There is no substitute for length. 20+ random characters and you are probably fine, if they are truly random.

[Paddy Landau]

… I prep them for Dropbox via encrypting using 7z AES

Sorry if I didn't make myself clear.

Dropbox won't accept files from an encrypted file system.

So, for example, ext4 running on top of LUKS, or ecryptfs on top of ext4, won't be accepted. Files running on plain ext4, without LUKS, ecryptfs, fscrypt, etc., will be accepted. If the file itself is encrypted using 7z AES, that's fine.

Dropbox also won't accept files from anything other than ext4. It won't even accept files from an NTFS partition even though it might be shared with Windows, where it is accepted!

Dropbox has explicitly (it's not an error; it's deliberate) refused to accept files on anything other than unencrypted ext4. This rules out RHEL (Red Hat Enterprise Linux), which doesn't use ext4. It rules out every company, charity, sole trader, professional, etc. in Europe because of the GDPR rules. It rules out any self-respecting organisation outside Europe because encrypted storage is de facto required. It rules out many individuals, like me, who refuse to use unencrypted storage.

In other words, Dropbox no longer supports Linux.

So, as Geoffrey_Arndt says, with that behaviour, we can't trust the company, because it's only a matter of time before Dropbox takes the one step further to remove its Linux app.

[Geoffrey_Arndt]

Good points . . . I did just finish a brief chat with Dropbox support. Not much clarity in their answer if "encrypted file" support will continue even for ext4 file systems (it seems that Dropbox pretty much doesn't ensure syncing for encrypted content).

Am waiting for more promised details, and will share if received. Meanwhile, I will join with others in LinuxLand to check out alternatives.

[David_Wright]

Thank you for all the comments and ideas.

I've found that pCloud suits my purposes best; it seems to do everything that Dropbox does, except that it supports Linux fully.

The one downside is that pCloud doesn't have a PPA.

Based on my past experiences with Dropbox competitors, one of the most important aspects (and possibly most difficult to assess) is the likely longevity of the provider. I signed up for Copy and thought that as it was backed by a storage business it would be available for the long haul . . . . and then they shut it down.

Does anyone have views on the Strongest-of-the-Rest of the Dropbox alternatives?

[TheFu]

Self host it using F/LOSS. Then you aren't at the whim of someone else.

Spider oak has a good rep within the Linux community.

[ghostis]

So, ext4 running on ecryptfs, fscrypt or LUKS won't count! Given the EU's GDPR and other reasons, this essentially means that Dropbox has given up on Linux.

LUKS operates at the block level so it seems to work fine. My Dropbox folder is on ecryptfs on Ubuntu 16.04. I get the warning when I run "dropbox start". So, I did a quick test:

mkdir ~/Dropbox_Image
cd ~/Dropbox_Image/

dd if=/dev/urandom of=./Encrypted_Dropbox_Image.img bs=1M count=2500
2500+0 records in
2500+0 records out
2621440000 bytes (2.6 GB, 2.4 GiB) copied, 241.55 s, 10.9 MB/s

sudo losetup /dev/loop0 ./Encrypted_Dropbox_Image.img

sudo cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha256 --iter-time 5000 --verify-passphrase luksFormat /dev/loop0

WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:

sudo cryptsetup luksOpen /dev/loop0 dropbox_encrypted_image

sudo mkfs.ext4 -j /dev/mapper/dropbox_encrypted_image  
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 639488 4k blocks and 160000 inodes
Filesystem UUID: 45b4f779-5a44-43a0-b104-49b673cb7bef
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912

    Allocating group tables: done                                                                                                                                                                                                                                                                                           
    Writing inode tables: done                                                                                                                                                                                                                                                                                              
    Creating journal (16384 blocks): done                                                                                                                                                                                                                                                                                   
    Writing superblocks and filesystem accounting information: done


mkdir ~/Dropbox_New_FS_tmp

sudo mount /dev/mapper/dropbox_encrypted_image ~/Dropbox_New_FS_tmp/

sudo chown -R  username:usergroup ~/Dropbox_New_FS_tmp/

rsync -av ~/Dropbox/ /~/Dropbox_New_FS_tmp/

dropbox stop

mv ~/Dropbox ~/Dropbox.SAVE

mkdir ~/Dropbox	

sudo umount ~/Dropbox_New_FS_tmp/

sudo mount /dev/mapper/dropbox_encrypted_image ~/Dropbox

mount | grep Dropbox
/dev/mapper/dropbox_encrypted_image on /home/username/Dropbox type ext4 (rw,relatime,data=ordered)

dropbox start

Now I don't get the warning.

I made a test file in the LUKS mounted tree and it appeared in the Dropbox app on my phone.

Note 1: To be clear, in this test, files are plaintext on Dropbox's servers, but encrypted on my local SSD - as they were before. Transparent encryption such that files are encrypted on Dropbox's servers is a different animal (but not hard as far as I can tell).
Note 2: I used a loopback file. You can also use a VM disk image or second physical drive.
Note 3: I have the Dropbox free plan, so a little over 2GB is fine for the file. Adjust your loopback file size accordingly.
Note 4: Change username to your username and usergroup to your user's personal group (usually these have the same name).