CryFS

Last reviewed Sep 13, 2026 · 855 words

Two people can look at the same encrypted Dropbox folder and learn very different things. With gocryptfs, they see how many files you have, how big each one is, and the shape of your directory tree. With CryFS, they see a flat pile of identically sized 32 KB blocks and nothing else. That metadata protection is the whole reason CryFS exists, and it is real. The price is a filesystem that is noticeably slower than the alternatives, and a hard rule that most people learn the painful way: never mount the same CryFS vault on two machines at the same time.

What it hides and how

CryFS splits every file into fixed-size blocks, encrypts each block with AES-256-GCM by default, and stores them under random names in the base directory. Directory structure is stored inside blocks too, so the on-disk layout reveals only the total size of the vault, rounded to a multiple of the block size. A 3 KB text file and a 3 GB video are both just contributions to a pool of blocks; nobody watching the cloud folder can distinguish "she has 12,000 small files" from "she has 40 large ones". The key comes from your password through scrypt, and the vault's configuration lives in an encrypted cryfs.config file in the base directory.

The design was published as a master's thesis in 2015 and has held up; the project is LGPL-3.0, 2,305 stars, and maintained at a slow, careful pace with long gaps between releases.

Mounting is two commands

CryFS is a FUSE filesystem. On Linux, install it from your distribution's repository (Debian, Ubuntu, Fedora, and Arch all package it) and run:

cryfs ~/Dropbox/vault ~/Private
# ... work in ~/Private ...
cryfs-unmount ~/Private

The first invocation creates the vault interactively, asking for a password and offering to change the cipher or block size. Everything you write to ~/Private appears as blocks in ~/Dropbox/vault, which your sync client uploads as usual. macOS works through macFUSE; Windows support via WinFsp exists but the project labels it experimental, and I would not trust it with the only copy of anything. Memory use is tiny, 64 MB or less, because the work is CPU-side encryption on the block path.

Larger block sizes reduce overhead on big files but leak a little more about vault size granularity; the default is a reasonable middle.

The sync trap

The block store is designed to be uploaded by a dumb sync client, and that is exactly the problem. If the vault is mounted and written on your laptop while another machine also has it mounted and writes, the sync tool sees two versions of the same block and either keeps one (silently losing the other's write) or creates a conflicted copy that CryFS cannot read. The result is a vault that reports I/O errors on some files with no indication of which ones. CryFS does not do multi-writer conflict resolution, and the documentation says so plainly.

The safe pattern is one writer at a time: unmount on the desktop, let the sync finish, mount on the laptop. With Syncthing that means waiting for the folder to show "Up to Date" before mounting elsewhere. With rclone-based push to object storage, the same rule applies, and since rclone has its own crypt backend with file-level encryption, it is worth asking whether you need CryFS on top at all.

Back up the cryfs.config file separately. Losing it, even with the password, means losing the vault.

Speed, and where gocryptfs wins

Because every read or write touches whole 32 KB blocks and the directory tree lives inside encrypted blocks, operations that are cheap on a plain filesystem get expensive: listing a folder with 5,000 files, rsyncing into the vault, or opening a large photo library. In my use it lands at roughly a third to a half of gocryptfs throughput on the same disk, and directory-heavy workloads feel slower than that number suggests. gocryptfs is faster, safe to use with concurrent readers, and leaks the structure and sizes that CryFS hides. Cryptomator, which is not in this directory, takes a middle path with chunked files and a friendlier GUI.

So the split is about your threat model. If the cloud provider knowing you have 40,000 files in 300 folders is a problem, CryFS. If you mostly want the contents unreadable and care about speed and multi-device convenience, gocryptfs. The file sync category covers the tools that move the blocks around either way.

What I'd do

Use CryFS for a single-writer archive that lives in a commercial cloud folder: tax records, scans, the things you rarely open but must not expose. Mount it on one machine, unmount before switching, keep cryfs.config and the password in your password manager, and test a restore onto a fresh machine once a year. For the working files you edit daily from two laptops, use gocryptfs or rclone crypt and accept the metadata leak.