AirDrop Not Working on a Mac: Check the Interface It Runs On

AirDrop fails in a way that gives you nothing to work with: the other device simply is not there. No error, no explanation, just an empty sharing sheet. The reason it is so opaque is that AirDrop depends on a piece of networking most people never see — a dedicated wireless interface that has to be up before any of the usual advice matters.

The checks below were run on macOS 26.5.2 and are all read-only or reversible. Whether a transfer between two specific devices succeeds is not something a single machine can establish, so the last section is about narrowing that down rather than claiming to have reproduced it.

The interface AirDrop actually runs on

AirDrop does not go over your Wi-Fi network. It uses Apple Wireless Direct Link, which appears on a Mac as its own network interface:

$ ifconfig awdl0
awdl0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether XX:XX:XX:XX:XX:XX
	inet6 (redacted) prefixlen 64 scopeid 0xd
	media: autoselect
	status: active

The hardware address and IPv6 address are replaced above; the flags and status are as printed. UP, RUNNING and status: active together are what a working AirDrop looks like at this level. An awdl0 that is down, or missing entirely, explains the empty sharing sheet completely and points somewhere quite different from the usual advice.

Three consequences follow from this, and they are the reason so much AirDrop troubleshooting sounds like superstition:

• Wi-Fi has to be on even when you are on Ethernet, and even with no network joined. AWDL rides on the Wi-Fi radio. Turning Wi-Fi off to “use the faster wired connection” turns AirDrop off with it.
• Bluetooth is for discovery, not transfer. The two devices find each other over Bluetooth LE, then the file goes over AWDL. That is why AirDrop can see a device and still fail to send.
• Some VPN and network utilities interfere. Anything that captures all interfaces or filters at the packet level can take awdl0 down without ever mentioning AirDrop. Disconnecting the VPN and re-checking ifconfig awdl0 is a two-command test.

Both radios have a one-line answer that does not involve looking at menu bar icons:

$ networksetup -getairportpower en0
Wi-Fi Power (en0): On

$ system_profiler SPBluetoothDataType | grep "State:"
          State: On

On most Macs the Wi-Fi interface is en0; on models with Ethernet it can be en1, and networksetup -listallhardwareports tells you which. Both readings need to say On before anything further is worth trying.

Check who you are discoverable by

“Contacts Only” is the single most common reason a Mac never appears on someone else’s screen, and the setting is easy to have changed without remembering. It has a definitive command-line answer:

$ defaults read com.apple.sharingd DiscoverableMode
Everyone

The three values are Everyone, Contacts Only and Off. Reading it beats hunting through the interface, where the control lives in the AirDrop section of Finder’s sidebar and also in Control Centre, and where recent macOS versions time “Everyone” back down to contacts after a while rather than leaving it on indefinitely.

Contacts Only carries requirements that are worth knowing before you blame the hardware. Both devices need to be signed in to iCloud, and the sending device’s Apple Account email or phone number has to be in the receiving device’s Contacts. Two Macs signed in to different Apple Accounts, neither of which has the other in Contacts, will not see each other however long you wait — and switching one of them to Everyone confirms that in seconds.

The firewall setting that blocks it silently

macOS has an application firewall with an option to block every incoming connection. It is off by default, and when it is on AirDrop receiving stops working with no message at all. Both parts can be read without sudo:

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
Firewall has block all state set to disabled.

Those two are independent: the firewall being enabled is fine, and “block all incoming connections” is the one that matters here. If the second command reports it enabled, turn it off in System Settings under Network > Firewall > Options and try again before changing anything else.

Restarting the AirDrop daemon

AirDrop is run by sharingd, which also handles Handoff and Universal Clipboard. When a Mac used to appear and suddenly does not, restarting it is faster and far less disruptive than rebooting:

$ pgrep -l sharingd
1290 sharingd

$ killall sharingd
$ pgrep -l sharingd
2458 sharingd

It comes straight back with a new PID, because launchd restarts it — the same arrangement that makes relaunching Finder safe. The visible effect is brief: AirDrop and Handoff are unavailable for a second or two while it restarts. Nothing else needs doing afterwards.

If the sharing sheet was showing a device that has since gone away, or showing nothing where a device clearly is, this clears the stale state that causes it. If the problem comes back within minutes, the cause is upstream of sharingd — go back to awdl0.

You can also watch it work. Its log subsystem is readable live, which tells you whether the Mac is advertising itself at all:

$ log stream --predicate 'subsystem CONTAINS "sharing"' --style compact
2026-07-20 15:22:00.415 Df sharingd[2458] [com.apple.sharing:Handoff] Request to advertise <private> with options <private>
2026-07-20 15:22:00.417 Df sharingd[2458] [com.apple.sharing:Handoff] Started advertising <private> as <private> with options <private>

The <private> markers are the unified log redacting values itself, not something removed here — device names and identifiers are censored by default. Even so, “Started advertising” appearing on a loop is a clear signal that this end is broadcasting, and complete silence from the subsystem while you open the sharing sheet is an equally clear signal that it is not.

When the problem is the other device

Everything above establishes that this Mac is ready. A transfer needs both ends, and the checks split cleanly: run the awdl0, DiscoverableMode and firewall checks here, then work through the equivalent settings on the other device rather than repeating them on this one.

A few things that reliably matter on the far side. On iPhone and iPad, AirDrop has its own entry under Settings > General > AirDrop, and Personal Hotspot being active suppresses it. Both devices need to be awake — a sleeping Mac does not advertise. Distance is real but usually overstated: within the same room is plenty, and a wall between the two devices matters more than the metres do.

If two devices both check out individually and still cannot see each other, toggling Wi-Fi off and on at both ends resets the AWDL association, which is the thing that actually has to be re-established. That is also why the folk advice of “turn Wi-Fi off and back on” works often enough to keep circulating — it is doing something specific, just not the thing people assume. When Wi-Fi itself looks unreliable rather than AirDrop, the wdutil diagnostics give a clearer picture than the menu bar icon does.