Showing results for 
Show  only  | Search instead for 
Did you mean: 
Learn more about how Connie, a member of the Community, uses Dropbox here!

Dropbox files & folders

Get in sync with the Dropbox Community. Our members can answer all your questions on Dropbox files and folders. Join a discussion or start your own today.

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dropbox client warns me that it'll stop syncing in Nov, why?

Re: Syncinc warning - Linux sync on an NTFS drive

Explorer | Level 4

This looks to be the best reply to this threads. I would recommend everybody doing the same.


-$99 a year

Re: Unsupported filesystem btrfs

Explorer | Level 4

Thanks, I am also sharing some copy paste responses here

<img src="">

Let's all contribute with similar screenshots.

-$99 a year

Re: Syncinc warning - Linux sync on an NTFS drive

Helpful | Level 6

Jane - what is the point of "closely monitoring" the thread if no useful replies are given.
So far no explanation as to why more modern and better file systems, which work at present _and_ support xattr are not being supported.
Why the relatively short notice period - when, for many people, the only solution would be a rebuild of their computer - not something to be undertaken lightly
Any change that dropdox will delay this for at least 6 months?

Re: Syncinc warning - Linux sync on an NTFS drive

New member | Level 2

Re: Syncinc warning - Linux sync on an NTFS drive

New member | Level 2

+1, very annoyed. 

I present a ZFS (ZOL) filesystem via samba to a proxmox instance (ubuntu 16.04) running the dropbox daemon.   i do zfs snapshots of the dropbox filesystem and can also do snapshots of the instance.  works perfectly.  i've been hands off on this for 2 or more years now; just works.  others will be using similarly architected solutions that work for them.  until now..

i think we all agree that anyone who knows what xattr is knows that it's not a  feature exclusive to ext4.  As such it's not a valid reason and represents the insult to the injury.

When i rearchitect i'll consider all options including moving to a different file-sync platform.  it's unlikely that i'll change filesystems, as i use the method described for many other instances and it's dropbox itself (not the filesystem) that has asserted itself as the weakest link here.

ecryptfs workaround, my solution

Explorer | Level 4

Dropbox ecryptfs workaround
- Dropbox files are stored in an unencrypted partition. If you want them encrypted on the HDD/SSD this isn’t for you.
- Host system Linux Mint 18.3 Cinnamon 64-bit.
- My system is single disk but used the default LVM install. If you don’t have LVM you’ll have to change this appropriately.
- / took all the space in the LVM so it needed to be shrunk to provide space for the unencrypted Dropbox partition.

Boot w/ external media so file system not mounted
Detect and activate the LVM volumes: # vgchange -ay

Check file system size
Mount the LVM partition. I opened nemo and clicked on the volume to mount it.
# fdisk -l to get size in bytes, divide by 1024^2  to convert to MiB
Now unmount it. Again nemo for me.
For the next step you need to know the volume group and logical volume that will be resized
To identify volume groups and logical volumes within: # lvscan
Make sure file system is clean: # e2fsck -f /dev/[volumegroup]/[logicalvolume]
Repeat e2fsck until file system clean

Shrink ext4 file system
Shrink by amount of available Dropbox storage (e.g. 2GB)
# resize2fs -p /dev/[volumegroup]/[logicalvolume] [(size from fdisk -l) – (your Dropbox allocation)]
# resize2fs -p /dev/mint-vg/root 34344M
I used MiB because I thought that would waste less space based on where filesystem boundaries fell.

Shrink the logical volume to the new file system size
Reduce the size of the logical volume (reduce to or below size ext4 system shrunk to)
# lvreduce -L [newlvsize] /dev/[volumegroup]/[logicalvolume]
# lvreduce -L 34344M /dev/mint-vg/root

Create new logical volume
# lvcreate --extents 100%FREE mint-vg --name drpbx

Format the volume
I used the disks application to format to ext4
We’re done with the external media running the pc

Boot from hard drive and set automount parameters
Create folder OUTSIDE your ecryptfs encrypted home directory to mount to, e.g.  /media/<user_name>/drpbx
Use disks program
Select the Dropbox partition
Turn off automatic mount options
Insert “rw,user_xattr,” at the beginning of the mounting parameters
Change the mount point to /media/<user_name>/drpbx
Set file system type to ext4
Save changes

Final config
Reboot from internal drive again
Find the new volume’s guid:
# blkid
/dev/mapper/mint--vg-drpbx: UUID="<long-hex-string>"
Make sure it is mounted: ll /media/<user_name>
If it isn’t, use nemo to mount it
Change owner and group to <user_name>:
# chown <user_name>:<user_name> /media/<user_name>/drpbx
change permissions so group and other have read and execute
# chmod g+rx,o+rx /media/<user_name>/drpbx

Install python-gpgme
Create a Dropbox folder inside the mount point, e.g. /home/<user>/drpbx/Dropbox
Dropbox requires the folder to be named exactly Dropbox
Install Dropbox
Use the Preferences… option from the Dropbox menu and select the Dropbox destination folder
In the Dropbox app select Preferences… and then the Dropbox folder. Files will be synced there.

But it gets weird. A folder named Dropbox must be selected or the sync won’t start. Once the sync starts it creates a child Dropbox folder within the selected Dropbox folder and syncs everything there.
The final path will always be /<mount_point>/Dropbox/DropboxDropboxIllustration.png




Re: Syncinc warning - Linux sync on an NTFS drive

Explorer | Level 4

So, today I went the distance and gave in to the powers that be. Only because I'm coerced into using dropbox through a collaborative organization I participate in. Like many others, my root filessystem is btrfs and I don't feel like convincing the others what a mental decision DB has made for participants like me.

I created a 2G sparse image to hold dropbox sync mountpoint and format ext4:

$ dd of=dropbox.img bs=1k seek=2M count=0
$ mkfs.ext4 dropbox.img

(The possibility of creating a sparse image was the final drop that convinced me this wasn't as bad a solution I always thought it would be).

I created a small script that mounts the image to the home Dropbox folder, but only if it isn't mounted already:

-- --

if ! mountpoint -q /home/martin/Dropbox; then sudo /bin/mount /home/martin/.local/var/dropbox/dropbox.img /home/martin/Dropbox fi

Unfortunately, only root can do that, so had to add passwordless execution of mount for the adm group I happen to be member of (/etc/sudoers)

# Members of adm group can mount without pwd 
%adm    ALL=NOPASSWD: /bin/mount

Make sure this line is below any other matching line or else it won't match.

I'm running KDE Plasma5, which offers startup applications and scripts. Scripts can be loaded "Before session startup", which is the only way to be certain to load the mount before dropbox desktop application starts (this all assumes no changes to default dropbox installation).

I could have done this in /etc/fstab, but since it's a user home directory mount, I decided to make it a user-session only thing.

So, in the end, am I happy with DB's decision? No! Did I solve it so that it's out of the way and I can keep collaborating without reformatting my disk or sacrificing multiple G's of storage: yep.


Explorer | Level 4

My PC does not contain or store files outside the operating system.
I use an external disk to store my files, disk that I disconnect from the computer for security reasons.
The external disk is in NTFS format for 5 years and I do not trust to change it to EXT4.
I want to continue using this file synchronization format.
Thank you.

Re: syncro

Helpful | Level 5

I'm in contact with Dropbox support and figured I'd post my initial arguments here:

"I apologize for my aggressive communication earlier (my initial communication was quite rude). These changes are unnecessary and I had spent several hours prior to this email working on a solution for myself. My work doesn't strictly require Dropbox, but trying to collaborate w/o Dropbox is very difficult as it's ingrained in their workflows. Since Dropbox goes straight from a free tier to a 1 TB tier, I'm forced into picking this option instead of something more reasonable like 100 GB. Using some spare space on my disk, I setup a LUKS encrypted 16 GB device and can access shared files again, but can only have a portion downloaded at a time. This is extremely frustrating, difficult to use, and not worth the cost. I'm currently trying to convince my work to transition to Google One or an end-point encryption option like SpiderOak. Furthermore, regardless of how it hurts my work performance, I can't support Dropbox if the change goes through.


However, I want to argue that these changes are pointless anyway. As listed here (, every major file system supports xattr as xattr is used for access controls, permissions, etc. Thus, the answer given that Dropbox is dropping support for all but one file system per operating system is untrue. While Ext4 may be the most common user PC file system for Linux users, many users and even more business applications utilize file systems with built-in snapshots, compression, etc. such as ZFS, Btrfs, etc. Dropping support for these systems despite their support for xattr is arbitrarily limiting your pool of users for no perceivable gain.


Beyond, Linux users, this change is quite damning to any non-stereotypical setup. I know people who have a dual-boot Windows/Mac machine with the Mac on a FAT file system, or at least mounting one, so that Dropbox is only synced to one place on their hard drive but accessible by both operating systems. By only supporting APFS for Apple, they're losing this ability even though FAT is supported. Many Linux users also use FAT, yet they are suddenly are losing Dropbox as well. If you support FAT, then support FAT everywhere, not just FAT on Windows. Instead of checking for the OS and FS adn  giving up if it's not your predetermined combination, I recommend testing for xattr and proceeding if it exists.


Furthermore, beyond using xattr, Dropbox should be agnostic to the file system. File systems act as a layer for a reason. Software doesn't need to know what type of file system it is writing to, it simply calls write and the kernel will handle the call from there. This includes eCryptfs which is just a layer to another file system anyway. eCryptfs will encrypt the data and hand it to the underlying file system. Software writing data doesn't care if eCryptfs exists or not, it is handled perfectly at a lower level.


In brief, this change is arbitrary and damaging and the response given by Dropbox as to why this is necessary is demonstrably false. It appears your hurting your users and income for no good reason. If there is an actual, engineering reason behind this change, I want the real answer before I'm satisfied."

Re: How to run Dropbox on RHEL / Centos / Scientific Linux (glibc 2.17)?

New member | Level 2

How long until DropBox works on CentOS again (with only glibc 2.17)? Ever since Oct 15, 2018, everything with DropBox has been HORKED!!!!


Now I guess I'll have to upgrade everything to ownCloud and get rid of everything that was using DropBox. This is going to take me many hours of suffering, which is very irritating!!

Which Dropbox integrations are you using while working from home?
Who's talking

Top contributors to this post

What do Dropbox user levels mean?
Need more support?