AirDrop is not working after downloading and installing “Dropbox for macOS on File Provider,” which appears to be v215.4.7202 on a Mac mini M4 Pro running macOS Sequoia 15.2 (build 24C101).
Now whenever I AirDrop a file from my iPhone 15 Pro Max running iOS 18.2.1, the file ends up in /private/tmp instead of ~/Downloads, as you can see in this screenshot:
I posted this problem on Apple Discussion but the recommended solution was to do some “spring cleaning” consisting of “Backup, boot to Recovery mode, erase, install, restore only user data files,” which I’d like to avoid given all the work I did to relocate several directories to an external drive.
The Dropbox forum lists many instances of problems with Dropbox related to AirDrop during the past three years and the ones that I read seem to be due to installations that configure Dropbox to backup the ~/Downloads folder.
Moreover, the list of known limitations for this version of Dropbox that’s posted the Help Center includes:
Is ~/Downloads one of the folders you relocated to external storage?
It may be that AirDrop sees a symlink there and instead of following the link, it falls back to a backup location of the Unix-standard system temporary directory /tmp (which on macOS, is a symlink to /private/tmp.
If so, then consider leaving Downloads in the actual home directory and just move its contents. Or don’t keep files in Downloads for longer than necessary.
I always move files elsewhere or delete them shortly after downloads, because I don’t want that location to become yet another Documents directory, so if I was in your situation, I wouldn’t bother relocating Downloads, because nothing stays there for very long.
If this is not your situation (e.g. Downloads is still a real folder in the home directory), then it might be a Dropbox bug.
Update
I just ran some tests, and I believe that is the case.
On my own Mac, I found that if I rename Downloads, then AirDrop just fails. If I replace it with a symlink, then files end up in /private/tmp
If AirDrop doesn’t like symlinks, where the symlink points isn’t going to make a difference.
While macOS doesn’t let you set a different Downloads folder at a system level, you can set it per-application. Maybe not all applications, but is it enough to set it for the applications that drop the majority of files?
What I mean is, you can set Safari and other web browsers to use the Downloads folder on your external drive. Mail, too.
As I mentioned, indeed ~/Downloads was in fact a symlink that pointed my external drive.
Using the Finder, I deleted the symlink and replaced it with the Downloads directory that it pointed to on my external drive; drag-and-drop preserved its Extended Attributes:
nello@miniMe ~ % ls -l@e
total 0
drwx------@ 4 nello staff 128 Jan 22 12:39 Desktop
com.apple.macl 72
0: group:everyone deny delete
lrwxr-xr-x 1 nello staff 38 Jan 16 19:17 Documents -> /Volumes/Sidecar/Users/nello/Documents
drwx------@ 5 nello staff 160 Jan 22 13:14 Downloads
com.apple.macl 72
0: group:everyone deny delete
drwx------+ 93 nello staff 2976 Jan 18 08:40 Library
0: group:everyone deny delete
lrwxr-xr-x 1 nello staff 35 Jan 17 13:13 Movies -> /Volumes/Sidecar/Users/nello/Movies
lrwxr-xr-x 1 nello staff 34 Jan 17 13:13 Music -> /Volumes/Sidecar/Users/nello/Music
lrwxr-xr-x 1 nello staff 37 Jan 17 13:14 Pictures -> /Volumes/Sidecar/Users/nello/Pictures
lrwxr-xr-x 1 nello staff 35 Jan 16 19:26 Public -> /Volumes/Sidecar/Users/nello/Public
nello@miniMe ~ %
I tested AirDrop from my iPhone and it still put files in /private/tmp but after power cycling and logging in fresh AirDrop placed files in ~/Downloads, as expected. (Perhaps a simple log out/in would also have worked.)
If it happens again (but a reboot doesn’t fix it) you could always drag the private/tmp folder to the Dock. It should behave the same as the Downloads icon - displaying the contents if you click it.
But, of course, you’ll see everything in there. Many apps and system services create temporary files in that location. For example:
$ ls /private/tmp
MozillaUpdateLock-2656FF1E876E9973 com.apple.launchd.yHTF4X3Nbr/
adobegc.log powerlog/
com.apple.launchd.83BZ1qFeI3/
Also, you shouldn’t assume that anything in /private/tmp will exist there long-term. Many Unix-like systems have maintenance scripts to purge the contents of /tmp at boot-time, and many also have scripts to delete files in there that haven’t been touched for several days.
These cleanup tasks are to keep the system from falling over in the face of badly-behaved users and apps that create temporary files in that common location and do not delete them afterward.
As an extreme example of this, Linux systems often use a RAM-based file system for /tmp. Which guarantees that everything there goes away after a reboot, without having to actually delete any files. (If there’s not enough RAM for the contents, the RAM buffer can get paged out to the swap file, which although a bit roundabout, is functionally no different from directly writing files to the file system.)