Evidence
Every service Mountit can mount, and exactly what has been proved about it — verified with a date, blocked with a count, or never run at all. Not a logo wall. The verdicts on this page are read out of the conformance ledger the app’s own CI gates a release on, and the build fails if this page and that file disagree.
8 of 38 services have had the corpus run against them, over 10 committed records. Each record names the lane it came from — a real daemon, a vendor emulator or the local filesystem — and the lane names below are the ones in the app’s own registry rather than a description written afterwards. Heaviest findings first, because the findings are the reason the programme exists.
| Service | Standing | Records | Last run | Findings | of which capability claims |
|---|---|---|---|---|---|
| SFTP File protocols | Blocked by a finding | openssh-sftp 123 assertions | 2026-09-01 | 16 | 2 |
| Google Cloud Storage Object storage | Blocked by a finding | fake-gcs 123 assertions | 2026-09-01 | 13 | 2 |
| WebDAV / WebDAVS File protocols | Blocked by a finding | rclone-webdavwsgidav-webdav 247 assertions | 2026-09-01 | 9 | 3 |
| FTP / FTPS File protocols | Blocked by a finding | pyftpdlib-ftp 123 assertions | 2026-09-01 | 7 | 2 |
| SMB File protocols | Blocked by a finding | samba-smb 122 assertions | 2026-09-01 | 6 | 1 |
| S3 and compatible Object storage | Blocked by a finding | minio-s3moto-s3 243 assertions | 2026-09-01 | 5 | 1 |
| Local folder File protocols | Blocked by a finding | local-folder 123 assertions | 2026-09-01 | 4 | 2 |
| Azure Blob Storage Object storage | Blocked by a finding | azurite-azblob 121 assertions | 2026-09-01 | 2 | 0 |
Findings is the ledger’s own count of what stands
between a service and a clean record: an assertion tagged must that failed, or a capability the backend claimed and
the server then contradicted. The second column breaks the contradicted
capabilities out of that total — it is not added to it, because the
harness already records each one as a failed must.
A record goes stale 180 days after the run.
Per-service detail — which assertions, and what the harness saw — is on
each service’s own page, and the underlying records are committed files
in the app repository rather than a report somebody wrote afterwards.
memoryThe harness runs the same corpus against its own in-process reference
backend, which is evidence for no service anybody mounts. It is here
because it is the control: a corpus nothing can pass would produce
the same wall of failures as a corpus that finds real defects, and
this lane is what tells the two apart. It answered
63 of
63
assertions tagged must and
28 of
28
tagged should, with nothing failing and no capability
claim contradicted. Every failure elsewhere on this page is therefore
a fact about a protocol or a server, not about the test.
4 services have no conformance record and are not simply untested. Either a live suite in the app exercises them directly, or the read/write corpus cannot describe them at all — a read-only service would fail every writing assertion for the one reason it already declares on its own page, and a record saying so would be theatre.
A live suite in the app repository exercises this service directly, so the corpus is not the only thing standing between it and evidence.
Live-tested Verified against a live serverRead-only by nature. The corpus is a read and write contract; running it here would report failures the service already declares.
Not yet tested live Compile-verified; no live server reached yetRead-only by nature. The corpus is a read and write contract; running it here would report failures the service already declares.
Not yet tested live Compile-verified; no live server reached yetA live suite in the app repository exercises this service directly, so the corpus is not the only thing standing between it and evidence.
Live-tested Verified against a live server26 services have never had the corpus run against them, and this page will not imply otherwise. Most are commercial clouds that need a real account and a developer registration, or self-hostable servers that need a machine somebody has not yet stood up. They mount — they are in the app, and the code paths several of them share have been run — but that is a different claim, and it is made on their own pages rather than here.
must failed, and no capability the backend claimed was contradicted by what the server did. The record stands for 180 days and then has to be run again.Two ledgers feed these pages and they answer different questions. The coloured dot beside a service — the one on every backend page — comes from the coverage ledger and answers “has this ever been mounted against a real server?”. The standing on this page comes from the conformance ledger and answers “did it keep every promise when it was?”. A service can pass the first and fail the second, and several do. Neither page is allowed to contradict the other: the build fails if they do.
No, and the distinction is the point of this page. Every service here mounts: a volume appears, Finder browses it, files open. Blocked means something narrower and more useful — a lane ran the full corpus of assertions against a real server and at least one assertion tagged must failed, or the backend claimed a capability the server then contradicted.
Those failures are mostly about the edges: what error a create returns when the file already exists, whether a rename refuses to clobber, whether a name with an emoji in it survives a round trip. They are exactly the cases a person hits on the day something goes wrong, which is why we count them rather than counting successful mounts.
Because nothing has earned it yet. The bar is a whole corpus run with no must failure and no capability claim the server disproved — and the first eleven records found dozens of findings across every lane that has run. Publishing a green badge over that would be the thing this page exists to stop.
Several of the findings share one root cause in a layer under the protocols, so a single fix moves more than one row. When one does, the row here changes on the next build with nobody editing this page — the verdict is read from the app’s own ledger file.
Because the harness runs the same corpus against its own in-memory reference backend, and that lane passes every assertion in it. The reference is on this page as the control: it is the thing that separates “the corpus is broken” from “the corpus found something”.
From crates/mountit-conformance/status.json in the app repository — the file the app’s own CI gates a release on. This site does not decide which services are verified; it reads that file, and the build fails if this page and the app disagree by so much as a byte.
What is deliberately not published is the prose beside each verdict in that file: it names internal test hosts and the machine a run happened on. The counts, the dates and the verdicts are all here.
180 days. After that the record is stale and the lane has to be run again before the claim can stay published — a protocol implementation that was correct two years ago is a claim about two years ago.