Dropbox: The given path is invalid.

I'm working on updating from Omeka 1.5.3 to 2.1.4. Everything appeared to go well. Omeka runs and Dropbox appears to function except that when you add something from the Dropbox files folder, it returns an error, "The given path is invalid."

First I tried modifying the config.ini to make sure background.php.path had a valid setting.

Permissions are set to 777 for the Dropbox files folder. Our Omeka instance is using some symlinks for content: /usr/vvv/www/omeka/plugins/Dropbox/files is a symlink to /xxxxx/Dropbox/files and the permissions are following through.

I did double check the Security Settings to make sure the Allowed File Extensions and Allowed File Types allowed the types of files we are putting in the Dropbox/files folder.

When I looked at the code in the Dropbox plugin to see where the error text was located [DropboxFunctions.php line 73], it appears to be calling realpath(of the file) and comparing the dropbox_get_files_dir_path() to make sure it's in the realpath string. I'm wondering if symlinks are an issue and how to get Omeka to play nicely with them. I tried setting the PHP open_basedir setting but that keeps the Omeka site from functioning at all. Does anyone have any suggestions on what else I should look at?


If I comment out the first conditional check of the dropbox_validate_file() function, then the plugin appears to work fine in uploading content. It doesn't seem like the solution is to modify the plugin's code since updates would break it again.

My testing of what the PHP realpath() function returns when using a symlink for the Dropbox/files directory indicates that the first conditional in the dropbox_validate_file() function will fail if using a symlink because the directory of the plugin is not found via strpos in the realpath of the Dropbox/files symlink.

Is there some documentation I'm missing to configure Dropbox so that it can work with the files directory set as a symbolic link to another location?

Hmm, I had a whole post written about this but it appears to have disappeared.

Anyway, that realpath() check is there to guard against people trying to put things like ../../../../etc/passwd as the file to pull in from the dropbox.

I think the fix here would be actually adding another realpath(), this one in dropbox_get_files_dir_path, to account for where there's a symlink along the path to the Dropbox files folder.