We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
MacOS 13.0 Ventura, and Dropbox follows OneDrive in forcing the folder on the system drive
With Monterey, OneDrive implemented the new apis from Apple for online syncing that demanded its main location be a specific folder on the system drive. 8 months later, the MacOS community section of...
You should be able to fix all these issues with a symlink.
Create a symlink as described in this article - https://tommcfarlin.com/new-dropbox/
You can use this app if you don't want to use the terminal - https://www.macupdate.com/app/mac/10433/symboliclinker
You can set the folder to wherever you want, external drive, etc.
symlink won't fix this issue
in third party applications (e.g. adobe) it's following the file back to its actual path.
thats why third party sync clients (e.g. maestral or mountainduck) are not working either.
afaik they use symlinks, too.
it'll always be where the file is located / cached.
so far only google drive worked to not link to the cache location but its also different technology and i don't know if it has changed since the enforcement of the cloudstorage.
Okay i just checked with a new Installation of GoogleDrive (also Using the new Apple File Provider API), and i tried to put a SimLink in ~/Library/CloudStorage pointing to a Folder on my External Storage. Does not work, only Errors when it tries to start syncing. I guess macOS recognizes the SymLink, the Content of the CloudStorage Folder is managed by the OS.
I guess the only working Solution would be moving the Home Directory to the external storage... this is a huge mess and so bad
I'm not following how a symlink won't work. The actual path will be wherever you previously stored your Dropbox folder.
For example, if your Dropbox folder was previously on an external hard drive - e.g.
/MySSD/DropboxYou would then create a symbolic link to that folder, and put it in:
/Users/{username}/Library/CloudStorage/DropboxThe actual path is identical to your previous location. It's Dropbox that will use the symlink.
just tested this in photoshop and illustrator – when created in terminal (not as an alias), it does work.
this is new, this hasn't worked in previous versions. thanks for the note.
discofuel wrote:I'm not following how a symlink won't work. The actual path will be wherever you previously stored your Dropbox folder.
This won't work now. Dropbox no longer follows symlinks to sync what is on the other side of the symlink. Dropbox now syncs only the symlink itself. This is actually the correct behavior (and the lack of this correct behavior, until now, is why I haven't used Dropbox for the last decade), but in this case, the correct behavior, unfortunately, denies us a workaround to the newly introduced problematic limitation under discussion.
I'm not talking about Dropbox following symlinks within the dropbox folder; I'm talking about the Dropbox folder itself being a symlink. Dropbox won't even know it's a symlink.
@discofuel so you are running on the latest Dropbox Version on macOS with Apples File Provider API and you have SymLinked your ~/Library/CloudStorage/Dropbox Folder from your system drive to a different location (external drive?)?
In which order did you do your steps to make this work? We have 30 TB of files in our business dropbox, so the process has to be efficient 😄 Did you create the SymLink before clicking through Dropbox's Assistant on "migrating" to the new FileProvider API behaviour? Or did you perform the migration to the new Folder, and then "moved its content back" and created the symlink?
We have external Thunderbolt RAIDs with our Dropbox Folders on right now, so we need a solution for this... the alternative would be moving the home Folder, but our RAIDs are HDD RAIDs, no SSD... not sure how that will perform
