A few weeks ago I noticed that my system has slowed down so much I couldn't even move my mouse smoothly. I figured out that it was dropbox that was running 100% on one core and eating up a few tens of megabytes per second until there was nothing left to eat. It's happening only when something is updated on my account from location other than my local pc running arch. In translation - it was the downloading part that screwed it up as it was endlessly looping on downloading one file.
So I read on the wiki that there could be a permissions problem with ntfs partitions and that I shouldn't use mount paths with spaces. Well the later part is ok as I never use paths with spaces where I don't have to and the permissions problem wasn't there obviously for a long time. Nevertheless, I change the fstab entry a bit to reflect the wiki entry, but nope...that didn't help at all. Also I can write into partition and folder just fine, but it seems dropbox just can't. If I start the dropboxd manually via terminal, it doesn't complain about anything in particular and it still loops on downloading.
I also tried reformatting to ntfs again. No luck.
Then I reformatted to fat32 and voila...it worked as a charm. So...why does it work with fat32 and not ntfs? I'd rather not keep it as a fat32 if I don't have to.
Last edited by klothius (2013-06-30 10:52:11)
No idea if this helps or even if it is a case like yours http://ubuntuforums.org/showthread.php?t=2131423
Thanks for the link.
The OP asks about moving dropbox folder from ext4 to ntfs whereas I already have my dropbox folder in my ntfs partition (and I had it there from the start and it worked ok). Although the poster Henque19 seems to have the same issue as I am, so I'll be keeping an eye on the thread.
I have the exact same problem. I keep my Dropbox folder on an NTFS partition, which I share with other operating systems on my computer. I also saw the wiki section that read that having spaces in the mount path of the NTFS partition could cause a problem like this, but that's not the case for me at all as well.
Thanks for narrowing this problem down; I had no idea what was causing it.
Well I gave NTFS another try today and it worked...I then realized that after gparted finished its formatting, it mounted the partition by itself and did not read from fstab entry about permissions and such. I looked to see what's changed and voila...gparted mounted the partition with additional mount option 'default_permissions'.
It seems that by default (even when passing defaults as a mount option) ntfs-3g does not include default permissions and it causes at least one application to have issues (dropbox) and mounting the partition with that mount option fixes the problem. Now I don't know why every other app I have that writes and reads from NTFS partitions(except boot,home and root, every other partition from my total of 10 is in NTFS) does not have a problem but dropbox, but this seems to solve it.
So anyone know if it's easy to edit a wiki or anyone know who should I contact to put this in a wiki as it seems it's a wide spread problem?
Could you please post the fstab line for your NTFS partition?
/dev/sdc1 /mnt/DropboxPart ntfs-3g rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
Basically all those options except default_permissions is default when mounting via ntfs-3g. Of course you could also use UUID for partition location.
For some reason I had the "defaults" option explicitly specified in my fstab, and as I found out yesterday, adding "default_permissions" won't work in solving this problem as long as that's there.
Ah well, I'm happy that Dropbox is working again. Thanks for solving this mystery.
Last edited by n125 (2013-07-02 11:32:17)