You are here
PumWalters - Thu, 2012/11/22 - 13:25
Just tried to install dropbox on a TKL File server
Dropbox on Linux usually finds an issue and offers the solution:
Unable to monitor entire Dropbox folder hierarchy. Please run "echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches" and restart Dropbox to correct the problem.
However, in a container /proc/sys/fs/inotify/max_user_watches cannot be changed (even by root). Probably this file isn't owned by this container (instance) and is shared by all containers.
Questions:
- is it possible to change this status of individual files, i.e. add it to the container and not the OpenVZ framework
- is it perhaps better to create a VM (instead of a container)? What are the performance implication when the file server is shared between multiple VMs/Containers
- is it perhaps better to allow the host to sync dropbox and to allow all VMs & Containers access to those (and other) files? What are the performance implications here?
Forum:
I assume you mounted Dropbox on Windows or Mac
Dropbox does not like working with otherwise Shared Files and Folders. I have done a workaround on one Windows machine. I would recomend trying to mount Dropbox Natively on the FileServer itself, then individually having your Clients (Mac/Windows) try still to access those files.
Or if via Linux, point Dropbox to a different folder if you can
I have not put Dropbox on a Linux, much less a TKL box. If you have done so, let us know how.
I am reading from your comment the same type thing Dropbox likes to say on Windows (do not try to have Dropbox on a Shared Folder). If you can, Put Dropbox in its Own Folder Space, then Go claim it via Fileserver and see if that works.
You definitely DO NOT want the "shared folder" being also the DROPBOX POINTED FOLDER by more than one user. So, one Machine installs Dropbox, says this is their folder and then other Dropbox files drop into that folder.
Externally, perhaps, other users might have access to certain folders on that Dropbox FolderSet but they generally would not be running Dropbox themselves. All this depends upon how "aware" dropbox is if those other shares. DB may not like other shares being there, but DB also may not know.
Dropbox on the server works well so far
(I should mention that this is a 50 GB file tree; multiple copies on different VMs on the same server is nonsensical)
Currently I have Dropbox on the server shared with one container (as described here), which is a TKL file server that exposes the filetree to other VMs (via Samba etc). No other VM shares the Dropbox filetree directly, nor does the server directly change files (to avoid the problems mentioned by @L.Arnold). This seems to work for me (CAVEAT: I am the only user of this server and am therefore aware of potential editing conflicts on the same file from different locations, though it has happened at times :-)
Dropbox uses about 750Mb of memory and has used 8 minutes CPU time over 155 hours uptime.
Did you check Google?
It turned up quite a few results, all basically saying the same thing. That even if you do what the error messages suggests (which it seems you can't on an OVZ container) that it still doesn't actually fix it. To fix it you need to edit /etc/sysctl.conf:
and add the line:
(<Ctrl><X> - <Enter> to save and exit) then:
Apparently a reboot should demonstrate that it now all works...
Please note that I haven't tested to confirm that this works (but be great if you could).
Sources:
http://blog.koppi.me/2011/12/howto-dropbox-unable-to-monitor-issue-on-ub...
http://technologytales.com/2012/09/24/getting-rid-of-a-dropbox-error-mes...
http://www.mariusv.com/solve-the-dropbox-filesystem-monitoring-issue/
Add new comment