Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

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 &
exit

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.

share|improve this answer
    
Interesting. Can you explain a little bit more what this line and the modified file in general does? –  nixda Feb 12 '13 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 '13 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 '13 at 7:40
    
@bicycle I haven't been prompted to update my dropbox client since coming up with this solution. –  Michael Sep 1 '13 at 18:57

Put that file in it's own folder and share that folder with the other user. This way they are editing the latest version as are you. Be careful not to work on it at the same time.

share|improve this answer
1  
Updating my original question to reflect the fact that the folder containing the file in question is already owned by the other user. It makes no difference, Dropbox still ignores the current ownership/permissions and resets them whenever the file is synced to the machine. –  Michael Feb 11 '13 at 16:40

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.

share|improve this answer
    
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 '13 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 '13 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. –  Isaac Rabinovitch Feb 12 '13 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 '13 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 '13 at 5:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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