gocryptfs

Last reviewed Sep 13, 2026 · 843 words

gocryptfs encrypts a folder one file at a time, so a 4 KB edit to one document uploads 4 KB plus a little overhead rather than a whole container image. That is the entire reason it exists in a self-hoster's stack: it sits under a sync tool, whether Syncthing, rclone, Nextcloud or a plain cloud client, and turns "my files are on a server I do not fully trust" into "my ciphertext is on a server I do not fully trust". It is not a server. Nobody deploys gocryptfs; you mount it on the machines that touch the data and let something else move the encrypted result around.

How a mount works, in four commands

gocryptfs is a single Go binary that needs FUSE (fuse3 on current distros). Create a cipher directory, mount it as a plain view, work in the plain view, unmount.

mkdir ~/cipher ~/plain
gocryptfs -init ~/cipher
gocryptfs ~/cipher ~/plain
# work in ~/plain, then:
fusermount -u ~/plain

Inside ~/cipher you will find gocryptfs.conf (the master key, wrapped with your password through scrypt) and files with scrambled names in directories with scrambled names, each one holding exactly one encrypted file. Content is AES-256-GCM, names are AES-EME. The cryptography was independently audited in 2017 and the design document is unusually readable for a project this size. Lose gocryptfs.conf and every file is gone, so it is worth an extra copy of that one small file somewhere else.

For unattended use, -extpass runs a command to fetch the password (a password manager CLI, pass, a systemd credential) and -passfile reads it from a file. On a laptop I mount at login with a systemd user unit; on a headless box -idle 10m unmounts after inactivity so a stolen machine is not sitting there decrypted.

Pair it with sync, and mind the two rules

Point Syncthing or rclone at ~/cipher, never at ~/plain. The encrypted side is what leaves the machine. Two rules keep this from going wrong. First, do not edit the same file from two machines at once; the sync tool sees two different ciphertexts for the same name and creates a conflict copy whose contents you cannot inspect without mounting it. Second, exclude nothing inside the cipher directory: the gocryptfs.diriv file in each folder is needed to decrypt the filenames in that folder, and a sync filter that skips dotfiles or tiny files will quietly break a subtree.

rclone has its own crypt backend that does a similar job at the remote layer. The difference is where the plaintext lives: rclone crypt encrypts on the way up and decrypts on the way down, so files sit in plaintext on every client. gocryptfs keeps the local copy encrypted too and only exposes plaintext through the mount. For a laptop that might be lost, gocryptfs wins. For a server pushing a backup to a bucket, rclone crypt is simpler.

Reverse mode is the backup trick

-reverse flips the model: mount a plain directory and get a read-only encrypted view of it, without storing a second copy on disk.

gocryptfs -reverse -init ~/documents
gocryptfs -reverse ~/documents ~/documents.enc
rclone sync ~/documents.enc remote:backup/documents

That is an encrypted, incremental, off-site backup of a directory you continue to use unencrypted locally, with no staging area and no dedicated backup daemon. The 3-2-1 backup article covers where the copies should live; reverse mode is how I make the cloud copy without trusting the cloud. It suits a plain mirror; if you want deduplication and snapshots, restic or Borg with their own encryption is the better shape.

What it leaks, and where it does not run

Encrypted directories still reveal structure: how many files, their approximate sizes, their modification times, and the shape of the directory tree. Someone holding your cipher directory can tell you have 3,000 photo-sized files updated every Saturday. If that matters, you want a container-based tool, at the cost of the sync efficiency this whole page is about.

Linux is home. macOS works through macFUSE, Windows needs the separate cppcryptfs project (format-compatible, different code), and Android has a couple of compatible apps. If you need the same vault on every desktop from one project with a GUI, Cryptomator is the friendlier choice; if you are a Linux person with a terminal open anyway, gocryptfs is smaller, faster and lower-drama. The file-sync category has the sync tools it pairs with.

What I'd do

gocryptfs on every laptop for the folders that would hurt if the laptop walked, synced between machines with Syncthing pointed at the cipher directory. Reverse mode plus rclone for the off-site copy of the home directory. Keep a second copy of gocryptfs.conf and the password in your password manager, test a restore by mounting the synced cipher directory on a second machine this week, and never let a sync filter touch the inside of the vault.