Finder Not Responding on Mac: How to Relaunch It and Find the Cause

Finder stops redrawing, the spinning wheel appears, and clicking a window does nothing. Relaunching Finder is the standard first move, and it is safer than force quitting a regular app: Finder is managed by launchd, so it comes straight back on its own.

But relaunching only clears the symptom. If Finder locks up again a few minutes later, something is holding it — and on a Mac that something is usually a volume that stopped answering, not Finder itself. This page covers both halves: the three ways to relaunch it, and the commands that tell you whether Finder is even the thing that is stuck.

Three ways to relaunch Finder

All three do the same thing. Pick whichever you can reach while the screen is unresponsive.

• Hold Option and right-click the Finder icon in the Dock, then choose Relaunch.
• Press Option-Command-Esc and select Finder in the Force Quit window. The button reads Relaunch for Finder, not Force Quit — a hint at what is going on underneath.
• In Terminal, run killall Finder.

On macOS 26.5.2, killall Finder prints nothing and exits 0. Nothing is a good sign here — the only output you would get is an error.

If you want to check that killall can even find the process before you send it a real signal, signal 0 does exactly that and nothing else:

$ killall -0 Finder
$ echo $?
0

$ killall -0 Findr
No matching processes belonging to you were found
$ echo $?
1

That error string is worth recognising, because it is also what you get from a typo or the wrong capitalisation. The process is named Finder, exactly.

Why Finder comes back by itself

Finder is a launchd-managed job, which is why quitting it is a relaunch rather than a shutdown. You can watch the handover:

$ launchctl list | grep com.apple.Finder
58225	-9	com.apple.Finder

The first column is the current PID, the second is the last exit status of that job. On macOS 26.5.2 that second column reads -15 right after a plain killall Finder, and -9 after killall -9 Finder. A negative number means the previous instance was terminated by that signal — 15 is SIGTERM, which man killall confirms is the default (“By default, it will send a TERM”), and 9 is SIGKILL.

The PID changes within a second or two of the kill, without anything being started manually. So there is no way to “close” Finder for good from the command line, and no need to reopen it — launchd has already done that. The same mechanism runs the rest of the system services described in the launchctl guide.

Try SIGTERM before SIGKILL

Plain killall Finder sends SIGTERM, which lets Finder shut its windows down in order. killall -9 sends SIGKILL, which the process cannot catch or handle at all — window positions and open tabs are more likely to come back wrong.

There is a diagnostic in that difference. If killall Finder does nothing after ten seconds and the PID has not changed, that is not a stubborn app — a process blocked in the kernel never gets to run its signal handler. At that point -9 will usually work, but the interesting question is what it was blocked on, which is the next section. For the general rules on kill, pkill and killall, see how to kill a process on macOS.

Is it Finder, or a volume it is waiting on?

Three checks, none of which change anything on the system.

1. Read the process state

$ ps -Ao pid,stat,comm | grep '[F]inder.app'
58225 S    /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder

The STAT letter is the whole point. man ps lists them: S is “sleeping for less than about 20 seconds”, I is idle, R is runnable — all normal, even during a beach ball. The one that matters is U, which the same page defines as “Marks a process in uninterruptible wait.”

A Finder sitting in U is not busy and is not confused. It is blocked in a filesystem call that has not returned, which in practice means a network share that went away or a disk that dropped off the bus. Relaunching will not fix that, and often will not even work.

2. See whether anything else touching the disks hangs

df -h asks every mounted filesystem how much space it has. On a healthy system it returns in a few milliseconds. If df also sits there and has to be interrupted with Control-C, the fault is in a mount, not in Finder — Finder is simply the most visible thing waiting on it.

3. Sample the process

sample attaches to a running process and reports where it is spending its time. It needs no sudo for your own processes:

$ sample Finder 2 -f /tmp/finder-sample.txt
Sampling process 1537 for 2 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Sample analysis of process 1537 written to file /tmp/finder-sample.txt

Skip to the “Sort by top of stack” section near the end of the file. A Finder that is doing nothing wrong looks like this:

Sort by top of stack, same collapsed (when >= 5):
        mach_msg2_trap  (in libsystem_kernel.dylib)        8580
        __workq_kernreturn  (in libsystem_kernel.dylib)        3432
        semaphore_wait_trap  (in libsystem_kernel.dylib)        1716

Those are all “waiting to be given something to do”. A stuck Finder shows filesystem or network frames at the top of that list instead, and the framework names in them usually identify the culprit without any further digging.

What tends to hold Finder up

• A network share that went away. Run mount and look for smbfs, nfs, afpfs or webdav entries. A share whose server is asleep, off the VPN or on a different network is the classic cause of a Finder that hangs the moment you click the sidebar. sudo umount -f /Volumes/name forces it off; diskutil unmount force is the equivalent for a physical disk.
• Third-party Finder extensions. Cloud storage and sync apps add badges and menu items through a Finder Sync extension, which runs inside Finder’s own process space. pluginkit -m -p FIFinderSync lists what is installed; no output at all means you have none, and one line per extension otherwise. They can be turned off individually under General > Login Items & Extensions in System Settings.
• A folder Finder cannot finish reading. Tens of thousands of items, iCloud files that are not downloaded yet, or Quick Look generating thumbnails from a slow external drive will all stall a single window. Opening a different folder in a new window tells you quickly whether the whole app is stuck or just that view.

When relaunching stops helping

If Finder freezes again within minutes of every relaunch, treat the relaunch as a diagnostic that has already given its answer: the trigger is still there. Check STAT during the freeze rather than after it, because the state that matters disappears the moment Finder recovers.

A restart clears stale mounts that umount -f refuses to release, which is why “it went away after a reboot” is so common with this particular symptom — and also why the problem returns as soon as the same share is mounted again. Deleting ~/Library/Preferences/com.apple.finder.plist is the last resort that gets recommended everywhere; it does reset Finder to defaults, and it also throws away every view setting, sidebar entry and window arrangement you have. It is worth trying only once the process state has ruled out a hung volume, because a hung volume will survive it untouched.