When something will not mount
The failure modes we see most, in the order worth checking them.
Start with a diagnostic export
Settings › Advanced › Export diagnostics writes a file recording what the server said and what Mountit did with it. It contains no credentials and no file contents. Attaching one to a support message usually saves a full round trip.
The extension is not listed in System Settings
Move the app to /Applications — an app on a mounted disk image
cannot register a file system extension — then restart. macOS frequently does
not show a newly installed extension until the next boot.
The volume mounts, then disappears
Usually the server closed the connection: an idle timeout, a
MaxSessions limit already reached by other clients, or a firewall
dropping a long-lived TCP connection. Check the server's own logs first; the
timestamps will line up with the diagnostic export.
Finder is slow on one particular directory
A directory with tens of thousands of entries is genuinely hard, because Finder
insists on a stat and an icon for each one. The first listing pays the full cost;
subsequent ones come from the cache. If it stays slow, the server is likely
answering readdir slowly — test it with
time ssh host 'ls -la /that/path | wc -l' to see whether Mountit is
the bottleneck or the messenger.
A file name looks wrong
SFTP does not guarantee that file names are UTF-8, and a name that is not valid UTF-8 is still a real file that must be openable. Mountit round-trips the exact bytes rather than replacing them with question marks, so a name that was created in a different encoding displays oddly but continues to work — copy, rename and delete all address the right file.
Writes appear to succeed but the server disagrees
Check the write-back queue in the volume's activity view. A save returns once it is durable locally; the upload follows. If the queue is stuck, the export will name the error the server returned — most often a quota or a permission that differs from what the directory listing implied.