Mountit news

Evidence before logos

2026-09-01T00:00:00Z

Most storage tools print a logo wall. A logo wall does not tell you whether anyone has ever mounted the thing it is showing you, and the difference between “implemented” and “works” is exactly where people lose files.

So every service page on this site — all thirty-six, under Backends — carries the evidence level straight from our engineering ledger: mounted against a live server, verified against the vendor’s emulator, sharing a code path with a verified service, or built and never yet mounted. Nine of the thirty-six are verified — seven against live servers, two more against the vendor’s own emulator. The rest say exactly what they are, on the page you would read before trusting them with your storage.

When a service gains its live test, its page changes and nothing else has to. That is the whole idea: the marketing cannot drift ahead of the engineering, because it is generated from the same list.

The Switcher: bring your connections with you

2026-09-01T00:00:00Z

Nobody switches mount apps for features. They stay because their connections live somewhere else — an rclone.conf with two dozen remotes, a Cyberduck bookmark list, Transmit favourites, Finder’s own “Connect to Server” history. Re-typing all of that by hand is the real switching cost, so we built the importer first and called it what it is: the Switcher.

It reads rclone.conf (passwords included — the obscure encoding is implemented and verified against a real rclone binary, differentially), Cyberduck and Mountain Duck bookmarks, Transmit and ForkLift favourites, ExpanDrive drives, and the servers macOS itself remembers. Nothing is imported silently: you get a dry-run plan that lists every item, imported or skipped, with the reason, and only a step you take after that creates anything.

Two details matter more than the list of formats.

An rclone type = crypt remote — client-side-encrypted storage — works on the day you import it, because our crypt layer is byte-compatible with rclone’s. The importer does not take that on faith: for each crypt remote it derives the keys from your password and round-trips a filename through our own cipher before saying the remote will mount.

And your own OAuth credentials are yours. rclone’s documentation tells Google Drive and OneDrive users to create their own client id and secret; those import verbatim, which makes those backends work with no registration of ours in existence. rclone’s built-in client credentials are the opposite case: they are never shipped, never reused, fingerprinted and stripped on import, with a test that fails if a candidate ever carries one.

The Switcher is built and tested; it reaches you when Mountit does. The changelog is the honest ledger of when that is.

The conformance program

2026-09-01T00:00:00Z

Most of a storage backend’s cost is not writing the client code; it is discovering how one particular server deviates from the protocol. And the only honest answer to “does backend X work?” is “against which server?”. So the question now has a machine that answers it: a conformance harness that takes any backend, connects to a real server, and runs roughly a hundred and twenty assertions at it.

Every assertion is a bug somebody has shipped. A rename onto an existing name. A zero-byte file. A write past the end of a file. A filename of 255 bytes where the server meant 255 characters. Two names that differ only by Unicode normalisation — one entry on the server, or two? Each case is tagged must (the contract the volume layer relies on), should (a well-behaved server, a quirk to route around otherwise) or probe (an observation that becomes capability data).

The verdicts are not a private scorecard. Each run commits an evidence record — a date and the server’s own version string — and no service is shown as verified here without one, or with one that has gone stale. Eleven lanes are committed today, against real servers: OpenSSH, Samba, MinIO, moto, rclone’s WebDAV server, wsgidav, pyftpdlib, azurite, fake-gcs-server, a folder on disk, and the in-memory reference backend. So when a backend page says verified, there is a file in the repository that says against what, and when.

Being honest about this means saying what the records contain, because it is not a clean sweep. Only the in-memory lane passes all hundred and twenty assertions. Every live lane found something — sixty-two blocking findings across the ten of them on the first run, from an SFTP client that reports “already exists” as a generic I/O error to a WebDAV reader that panics on a server whose listings put a trailing slash on a file. Those are real defects in our code, found by exactly the machine built to find them, and each service now carries its own status and its own list of what is outstanding rather than a single word. A backend that says verified against a live server and has open conformance findings is telling you two true things at once.

Two services on this site say verified against a live server with no conformance record behind them: pCloud and plain HTTP. Their claim rests on their own live test suites and on the ledger’s prose, because neither can have a lane — pCloud has no emulator and no free test account, and HTTP is read-only, so a corpus of read-and-write assertions has nothing to say about it. That is written down in the repository beside the other thirty-four services, and the build refuses to publish a service as verified with neither a record nor a written reason there cannot be one. Twenty-six more services have no record at all and do not claim one; most are commercial clouds that need a real account, and each says which.

A green run against our in-memory backend is the floor, not the ceiling — it proves the corpus is coherent. The live lanes are where the findings live, and each one closed is a changelog entry.

How security notices will work here

2026-09-01T00:00:00Z

Before there is anything to announce, the process deserves to be written down.

Reports go to security@mountit.app. Mountit is small; a report is read by the person who can fix it, usually the one who wrote the code involved. We will not threaten you for one — the support page says so and this is it meaning the same thing.

When a fix ships, the announcement is published here with the Security notice label and mirrored in the changelog, tagged security. Security entries are never buried in “bug fixes and improvements”: an auto-updater that installs one silently denies you the one sentence that explains why the app restarted, and this page will not either.

The app has its own way to reach you first: signed announcements delivered inside Mountit, whose links are verified to point at this site and nowhere else. A security notice there and a security notice here are the same text, published the same day.

Both have an Atom feed, so you do not have to check by hand.