I have two machines, a Mac and a PC running Linux, that I am trying to keep a certain file synced between using Dropbox.

One of the files that I am syncing needs to be writable by another user (different UID on the same machine, not referring to another dropbox user) besides myself. To be more specific, this other UID is actually a daemon. So, either the file needs to be owned by that other user, or else write permission is needed for "group" and/or "other". Initially I have set it up this way on both machines. In addition, the directory containing the file is already owned (chmod 777) by the user that needs to have write access to the file.

However, whenever the file gets synced from one box to another, it appears that Dropbox completely ignores both sets of permissions, and changes the permissions on the newly updated file to be owned by me with permissions 0644 (rw for me, r for everyone else). If the file isn't owned by me it even changes ownership back to myself! As a result, the other user no longer has write permissions until I manually go in and re-chmod the file.

Additional things I have tried that have not worked:

  1. made sure the user account (for the "other user") on both machines has the same UID. Not sure why this would be necessary, since my primary account doesn't have the same UID on both machines.

  2. chmod u+s <dir> and chmod g+s <dir> where is the directory containing the file in question.

  3. changing ownership of the file to the other user and placing it outside the Dropbox directory, and creating a symlink to the file in the Dropbox directory. Dropbox actually deletes the symlink, leaves the original file (outside the Dropbox directory) unchanged, and creates a new copy of the file where the symlink used to be!

How can I set things up so that my permissions and/or ownership are preserved?

2 Answers 2


Ok, here is the solution I have found. Whether or not this will work with future versions of Dropbox is uncertain. I have opened a service request with Dropbox to try to resolve the problem further.

Overall, the solution is a combination of two things:

  1. Setting the umask for the Dropbox process so that newly created files have permissions of 0660. This is user read/write, group read/write, other none.
  2. Setting the group for newly created files to the group that needs to have write access to the files in question.

This solution will apply to all files in the Dropbox folder, not just a single file. In my case this is acceptable.

Under Linux, I modify the /etc/init.d/dropbox startup script so that the line invoking dropbox as a daemon reads:

HOME="$HOMEDIR" start-stop-daemon --umask 0006 -b -o -c $dbuser:$dbgrp -S -u $dbuser -x $HOMEDIR/$DAEMON

Adding the --umask 0006 accomplishes setting the umask, and the :$dbgrp portion of the -c option accomplishes setting the group to that the daemon belongs to.

On the Mac side, I run the following commands:

ps aux | grep -i dropbox

From this I can see the command-line options that started Dropbox and from this I extract the $mydropboxid used later. Then I quit Dropbox and open a command prompt and enter the following commands:

umask 0006
/Applications/Dropbox.app/Contents/MacOS/Dropbox -psn_0_$mydropboxid &

I plan to automate the above commands at some point so that I won't have to re-run these any time my machine is rebooted.

This handles setting the mask for newly created files so the group for a file has write access. However, in order to get the group set correctly I need to setgid the Dropbox cache directory - this so far has only needed to be done once:

sudo chgrp -R $dbgrp ~/Dropbox/.dropbox.cache
sudo chmod -R g+s ~/Dropbox/.dropbox.cache

It appears that all new files are first created under the ~/Dropbox/.dropbox.cache directory, so the above commands gives those new files the proper ownership and permissions that new files created by Dropbox has the correct group.

  • Interesting. Can you explain a little bit more what this line and the modified file in general does?
    – nixda
    Feb 12, 2013 at 8:08
  • The start-stop-daemon is a Linux utility that lets you control various settings under which a daemon runs. Most of the parameters are passed in a shell variables. The key modifications are the addition of "--umask 0006" which leaves R/W permission for user and group but removes it for others, and the addition of the group parameter (":$dbgrp") to the -c parameter, which sets the UID/GID the daemon process runs as). The Mac command is similar, but I haven't found a similar utility, so relies on setting up these settings in the shell that runs Dropbox.
    – Michael
    Feb 12, 2013 at 14:34
  • Does this apply to the current dropbox version as well? My dropboxd script is PAR=$(dirname $(readlink -f $0)) OLD_LD_LIBRARY_PATH=$LD_LIBRARY_PATH LD_LIBRARY_PATH=$PAR${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH exec $PAR/dropbox $@ and is located in ./.dropbox-dist/ and is managed through the supplied python script
    – bicycle
    Aug 8, 2013 at 7:40
  • @bicycle I haven't been prompted to update my dropbox client since coming up with this solution.
    – Michael
    Sep 1, 2013 at 18:57
  • @Michael, did Dropbox ever respond to your service request?
    – bbozo
    May 26, 2016 at 7:45

If you copy a file between two computers, the software that does the copying decides what the permissions are on the copy. For what you're doing, you need some fairly fine-grained permission mapping. Dropbox permission-mapping features are limited to preserving permissions if both systems run the same OS. No specific results are guaranteed for copying between two different OSs.

Even if you could figure out some way to use Dropbox the way you want, I'd advise against relying on it. Undocumented software quirks have a way of disappearing without notice. You need to look at file transfer tools that are designed with your use case in mind. My first choice would be rsync, which is standard on Linux distros, and easy to install on Windows, especially if you have Cygwin. And Cygwin is generally useful for people who have to work with both Windows and Linux!

Of course, rsync requires a direct-connection — there's no central server such as the one Dropbox provides. How you deal with that depends on the details of your network setup.

  • Yeah I agree with what you are saying about quirks. In my mind this often a good reason to stop upgrading software - if it does what you want, why risk newer versions breaking that!
    – Michael
    Feb 12, 2013 at 4:47
  • rsync isn't bi-directional, and doesn't automatically update every time a change is made to the file.
    – Michael
    Feb 12, 2013 at 4:47
  • @Michael You don't always have a choice about upgrading software; when it's cloud-based (like Dropbox) you never have a choice. And it's hard to see why bi-directionality or automatic copy are essential for what you're trying to do. Feb 12, 2013 at 5:05
  • As long as the service remains backwards compatible with the previous client you have a choice. And unless Dropbox can force everyone to upgrade right away, I doubt they could do something like making low level change to the protocol which would break old clients. The only way I can see they could do it is through some kind of transition.
    – Michael
    Feb 12, 2013 at 5:16
  • Regarding what I'm trying to do, I'm trying to maintain a set of files on two different machines and be able to modify either one of them at any given time, then jump to the other one a short time later and pick up where I left off, without having to do anything manually like start an rsync. This mainly because I might do the modification remotely (e.g. through a web interface), and there are issues like firewalls and latency which make it inconvenient to maintain a single centralized copy of the data.
    – Michael
    Feb 12, 2013 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.