Leaving
The hardest fair question about a paid tool that stands between you and
your own storage is: what happens to my data when I stop paying? This
page answers it with the actual configuration, not a reassurance. Your
files stay where they are, in the format they are in, and this is the
exact rclone stanza that reads them without us.
Mountit is not a storage service. Your files live in your bucket, on your server, in your provider’s account — we hold no copy and there is no Mountit-side database that has to be unwound. If you never switched on the encryption layer, the story ends here: your objects are named what they are named and any client that speaks the protocol reads them today.
If you did switch encryption on, that is the interesting case, and it is the one this page is for.
It is rclone’s crypt format. Not “inspired by”, not
“compatible with” in a brochure sense — the same bytes, implemented
against the same constants and tested against a real rclone binary.
crypt, byte for byteRCLONE\0\0 then a 24-byte nonceTwo stanzas: the inner remote — whichever storage you were already
pointing Mountit at — and the crypt remote wrapping it.
The inner one is ordinary rclone configuration and has nothing to do
with us; the second is the one that has to match what you set in
Mountit.
[mystore]
type = s3
provider = Other
endpoint = https://s3.eu-west-1.example.com
access_key_id = AKIA…
secret_access_key = …
[secret]
type = crypt
remote = mystore:my-bucket/my-folder
password = <rclone obscure 'your Mountit password'>
password2 = <rclone obscure 'your Mountit salt'>
filename_encryption = standard
directory_name_encryption = trueMountit exposes four encryption settings. Everything else rclone offers, it leaves at rclone’s own default — which is why most of this table says “leave the line out”.
| In Mountit | rclone key | Value |
|---|---|---|
| Password | password | the same password you typed into Mountit rclone stores it obscured. Let rclone config do that for you, or paste the output of rclone obscure '…' if you are editing the file by hand. Mountit stores the password itself, not an obscured form, so there is nothing to copy across — you have to know it. |
| Salt (optional, second password) | password2 | the same salt you typed into Mountit If you left it blank in Mountit, omit the line entirely. Mountit treats an empty salt and no salt identically, and both mean rclone’s built-in default salt — which is what rclone does when password2 is absent. |
| Encrypt file names | filename_encryption | standard when it was on, off when it was off Mountit only ever produces these two. It cannot produce obfuscate. |
| Encrypt folder names | directory_name_encryption | true or false, matching the switch |
| — not offered — | suffix | none Only needed when filename_encryption = off, and then it is mandatory. rclone’s default suffix is .bin and it will look for report.pdf.bin; Mountit appends nothing. This is the one omission that produces a stanza which looks right and finds no files. |
| — not offered — | filename_encoding | base32 — rclone’s default, so leave the line out Mountit’s encoder is fixed. base64 and base32768 are rclone-only. |
| — not offered — | no_data_encryption | false — the default, so leave it out Mountit always encrypts the data. |
| — not offered — | pass_bad_blocks, strict_names | defaults, so leave them out Mountit behaves like rclone’s defaults: a block that fails its tag is an error rather than a hole of zeros, and a name that will not decrypt is skipped rather than fatal. |
filename_encryption = off
suffix = nonerclone lsf secret:
rclone cat secret:some/file.txt | headMountit stores the password you typed, sealed in its own encrypted
record, and never shows it back to you — the field is write-only once
saved. rclone stores an obscured form of the same password, which is an
encoding rather than a secret, so there is nothing to copy between
them: you supply the plaintext to rclone config, or paste
the output of rclone obscure '…' if you are editing the
file by hand.
Which means the honest warning belongs here rather than in a footnote: if you do not know the password, nothing recovers your data. Not rclone, not us, not the provider. There is no escrow and no recovery code, because either would be a copy of your key held by someone else. Put it in your password manager on the day you set it.
Every Mountit encryption setting is a valid rclone setting — the reverse is not true. rclone can express these; Mountit cannot, so you will never have to translate one:
filename_encryption = obfuscate — Mountit does not implement it, and refuses to import an rclone remote that uses it rather than mounting it wrongly.filename_encoding = base64 or base32768 — same.no_data_encryption = true — same.If you switched Chunking on and a file was larger than the chunk size, it is stored as name.mountit_chunk.001, …002 and so on, plus a name.mountit_chunk.meta holding JSON with the original size, the chunk size and the part count. This is Mountit’s own naming and rclone’s chunker backend will not read it. Chunking sits outside encryption, so with the crypt stanza above rclone shows you the parts under their real names; join them in numeric order — cat name.mountit_chunk.[0-9][0-9][0-9] > name — and the result is the original file. (Not …chunk.0*: that glob stops at part 099, and cat would build you a truncated file and exit successfully.) Files at or below the chunk size are stored whole, under their own name, with no metadata object at all.
Mountit keeps .DS_Store, ._-prefixed AppleDouble files, .Spotlight-V100 and friends in the local cache instead of writing them to your server — the remote stays clean, and other clients do not have to look at them. The consequence when you leave: Finder state stored that way, such as a folder’s view settings, was never on the server and goes with the cache. File contents and file names are untouched.
On stores where replacing an object atomically means writing a sibling and renaming it, an interrupted write can leave one behind next to the real object. rclone will not list it through the crypt remote, because it is not a valid encrypted name. If you are looking at the bucket directly and see a name ending in .mountit-rewrite, it is a fragment and is safe to delete.
Because the alternative is asking you to take it on faith, and the whole argument for buying a tool that sits between you and your storage is that it is not a trap. A format we invented would be a lock-in mechanism whether or not we intended one; an rclone-compatible format is a commitment that survives us going out of business, changing our minds, or putting the price up.
It also disciplines the engineering. The suite that hands files back and forth with a real rclone binary is what keeps “compatible” from being an assertion that decays quietly between releases — and, as the questions below say, it is run deliberately rather than on every commit, because it needs an rclone binary present to run at all.
It is the same format, and it is tested as one. Mountit’s crypt crate has an interoperability suite that shells out to a real rclone binary: rclone must read files Mountit wrote, Mountit must read files rclone wrote, both must agree on the encrypted name of a nested path, a round trip through rclone must preserve the bytes, and the key derivation is checked on its own through rclone obscure. It was last run against rclone v1.76.
The honest caveat: those tests need an rclone binary present, so they are opt-in rather than part of every routine run. They are run deliberately, not automatically.
Then there is nothing to undo. Your files are on your server exactly as they are named and exactly as they were written, and any client that speaks the protocol — rclone, Cyberduck, aws s3, sftp, the provider’s own web UI — reads them today. There is no Mountit container, no database and no index for you to convert.
No, and neither can anyone else. The password is the key; there is no escrow, no recovery code and no copy on our side, because we never hold your data or your credentials at all. Mountit does not show a saved password back to you either — the field is write-only once saved. Keep it in your password manager the day you set it.
Not today. Import is one way: Mountit reads an existing rclone.conf, and Mountain Duck, ExpanDrive, ForkLift, Transmit and Finder favourites, but writes none of them. Rebuilding a remote from this page is a manual job — the parameters are all here, and there are not many of them. We would rather say that plainly than imply an export button exists.
Yes, and it is disposable. Each mount keeps a cache under Mountit’s own container: a SQLite file of metadata plus a directory of AES-256-GCM-sealed chunks, keyed per connection. Deleting the app deletes it. Nothing in it is needed to read your data from the server, and nothing in it needs migrating — but if you are leaving a shared Mac, deleting the app is the step that removes the local copies.