Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to use a shared Dropbox folder to make HTML files easily editable by several people, and am (re)mounting the Dropbox folder to somewhere in /var/www/ with the --bind option. I have the SELinux context set for the Dropbox folder so that items inside get a httpd_sys_content_t type, which httpd (on RHEL6) can read. This all works and the files are available on the website. Editing a file in the Dropbox folder on the web server also works (the SELinux context is retained).

However, when the file is updated via Dropbox (say, someone else edits the file), the resulting file on the receiving end (after Dropbox has updated it) always gets a context of user_home_t, and so Apache can't read the file and so a 403 Forbidden error results (until I go and manually restore the context).

I tried setting the context for ~/.dropbox/ to httpd_sys_content_t, which also works: the cache (?) files in ~/.dropbox/l/ get that context, but then the updated file in ~/Dropbox/ still gets user_home_t. This indicates that Dropbox updates the file somewhere else (presumably via its delta method) and then does an equivalent of mv to move it into the Dropbox folder (since under SELinux mv preserves the context of the origin and cp resets it according to the destination).


  1. I don't wish to disable SELinux (but doing so does fix the problem)
  2. Regarding the use of httpd_sys_content_t: I might eventually create a special policy to deal with these files which might be more sensible than just using httpd_sys_content_t but I'll worry about that later
  3. I could run a little script that did a restorecon -R on the appropriate Dropbox subfolder every 5 or 10 seconds, but would rather catch this earlier

So: where does Dropbox create the newly updated file before moving it back to the Dropbox folder? Any other thoughts on something else to try?



share|improve this question
up vote 1 down vote accepted

The temporary file is created in ~/Dropbox/.dropbox.cache/, then moved to its real location, to ensure atomic updates.

Workaround #3 should work – you can use incron, it would execute the command as soon as a file is changed.

share|improve this answer
Thanks, v. silly of me not to find the right cache location, but I was fixed on looking in ~/.dropbox/! – manyon May 15 '12 at 4:32

Your Answer


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.