securefs encrypts a directory in place, without a container file

A directory that decrypts itself

securefs is a filesystem in userspace, built on FUSE, with transparent encryption when writing and decryption when reading. The mechanism is simple to describe. It mounts a regular directory onto a mount point. The mount point appears as a regular filesystem where you can read, write and create files, directories and symbolic links. The underlying directory is automatically updated to contain the encrypted and authenticated contents.

That arrangement is the reason the project exists. The README's motivation section is about the friction of ordinary encryption: you have to encrypt files before committing them to the cloud and decrypt them every time you need to read or write, and those actions leave unencrypted traces on your hard drive. Manual encryption also prevents files from being synced efficiently. securefs is intended to make the experience smooth enough that security and convenience do not conflict, so that after mounting the virtual filesystem everything just works.

The audience is people with something to keep private, from sensitive financial records to personal diaries, and the cloud storage case is called out specifically, since the company and, in the README's phrasing, the NSA may get their hands on it.

The implementation is C++ with a CMake build, and the repository has the shape of a serious native project: main.cpp at the top level, CMakeLists.txt, a build.py driver, a vcpkg.json dependency manifest, overlay_triplets, protos, sources, a test directory, a Containerfile and a Dockerfile, plus format.sh and a .clang-tidy configuration. The last push to the master branch was on 2026-10-05, and the latest release is v2.0.0 from 2025-10-01.

How it differs from the encrypting filesystems you already know

The README names the crowded field it is aiming at: TrueCrypt, FileVault, BitLocker, eCryptFS, encfs, cryfs, rclone and gocryptfs. Then it makes a specific claim, that securefs is the only one with all of the listed properties. Whether or not you accept the word only, the list is the useful part.

Authenticated encryption means the ciphertext is checked as well as encrypted, so a tampered file is rejected rather than decrypted into rubbish, and the README ties this to being secure against chosen ciphertext attacks.

Probabilistic encryption means the same plaintext does not produce the same ciphertext twice, which is what gives semantic security, so an observer cannot tell that two files share content.

Efficient cloud synchronisation is the third point, and it is phrased as a contrast: not a single preallocated file as a container. This is the design decision that separates it from the container-based tools, and it is why the underlying directory is a normal directory of files that a sync client can copy.

The rest are details with real consequences: full 255 byte long file name components, which matters on filesystems with a shorter limit; optional file size obfuscation by random padding, so the length of a file does not reveal the length of the plaintext; optional case insensitive and case preserving behaviour matching the default of NTFS; and optional Unicode normalisation agnostic behaviour matching the default of APFS and HFS+.

Those last two are worth dwelling on, because they are compatibility features rather than security features, and they are the kind of thing that stops a user from discovering on day one that a file called README and one called readme cannot coexist.

Lite and full: a speed choice and a secrecy choice

There are two filesystem formats, and the difference between them is the central design decision in the project.

The lite format simply encrypts filenames and file contents separately, similar to how encfs operates, although with more security. The full format maps files, directories and symlinks in the virtual filesystem all to regular files in the underlying filesystem, with the directory structure flattened and recorded as B-trees in files.

Lite is the default, and the reason given is practical: it is much faster and features easier conflict resolution, especially when used with Dropbox, Google Drive and similar services. Conflict resolution is the sharp point. With a flat set of files, two devices writing the same file produce one conflict that a sync tool can surface. With a B-tree encoded structure, a conflict is a conflict about a whole directory of metadata, and a sync tool has no way to merge it.

Full mode leaks fewer information about the filesystem hierarchy, runs relatively independent of the features of the underlying filesystem, and is in general more secure. So the trade is explicit: lite is fast and syncs, full hides the shape of your directory tree and does not depend on the sync target's handling of symlinks or long names.

Full is no longer the default, and the README says to request it explicitly:

securefs create --format full

Whichever you pick is a decision you make once, at creation time, and it is worth reading the design document linked from the README before you commit a large directory to one or the other.

Creating and mounting from the command line

The usage section is a list of commands, and the shape of the tool is obvious from it.

Creating a filesystem takes a directory, and the password can be replaced by a key file:

# Creation
securefs create ~/Secret # Default parameters
securefs create ~/Secret --keyfile ./mykey # Use keyfile instead of password

Mounting takes the created directory and a mount point, and you unmount with Ctrl-C:

# Mounting
securefs mount ~/Secret ~/Mount # press Ctrl-C to unmount

Several options change the behaviour of the mounted filesystem. --max-padding 65535 randomly pads each file with at most 65535 bytes to obfuscate its size. --format full selects the B-tree format described above, and it can be combined with --case insensitive to match NTFS or --uninorm insensitive to match APFS.

Two options matter for the underlying directory rather than the view. --plain-text-names does not encrypt the filenames, which is a deliberate weakening of the confidentiality you get, useful when a sync tool or an indexer needs to see names. The background mount, with -b, takes a log path, and the example names the file securefs.thismaycontainsensitiveinformation.log, which is a good hint about what the log holds.

On Windows the mount point can be a drive letter, securefs m ~/Secret Z:, and the password can be changed afterwards with securefs chpass ~/Secret. The full set of options is in docs/usage.md, and the help commands are securefs --help, securefs m --help and securefs c --help.

What each platform needs before securefs will mount

The install section is mostly a list of platform prerequisites, and the differences matter because FUSE is not the same everywhere.

On Windows you need WinFsp and the VC++ redistributable installed separately. On Linux you need the libfuse-dev package, also called fuse-devel depending on the distribution. On FreeBSD you run pkg install fusefs-libs. On macOS you install MacFUSE.

For a binary, the Release page is enough. For a package manager, the README gives two routes. On Windows, WinGet, in a user scoped install and a system wide one:

winget install -e netheril96.securefs

sudo winget install --scope machine -e netheril96.securefs

On macOS, Homebrew, with a tap because the package is not in the main repository:

brew install netheril96/fuse/securefs-mac

Building from source needs vcpkg installed first, and then a Python driver script:

python3 build.py --enable_unit_test

There is also a container route, which the README presents as a way to build, test and run securefs, or to extract a fully static standalone binary, with Podman or Docker, without installing C++ toolchains or FUSE development libraries on your host. The helper script covers the three cases:

# Build the runtime image (securefs:latest) and builder image (securefs:builder)
./scripts/podman-build.sh build

# Extract a standalone static binary to ./build/securefs
./scripts/podman-build.sh extract

The Dockerfile behind it is a multi-stage build on alpine:3.20 that compiles a static libfuse 2.9.9 with link time optimisation, then fetches vcpkg at a pinned commit, and it works around musl and mimalloc compatibility with a stub linux/prctl.h.

The caveats, stated before you mount anything

Three warnings in the README deserve to be read before the first mount, because each one is a decision you make rather than a bug you discover later.

The first is about swap. The README recommends disabling or encrypting the swap and hibernation file, because plaintext and keys stored in main memory may be written to disk by the operating system at any time. An encrypted filesystem that is decrypted into memory is only as private as the machine's swap configuration, and every distribution ships swap on by default.

The second is the iCloud caveat. If you store securefs encrypted files on iCloud Drive, it might cause Spotlight Search on iOS to stop working, and the README is clear that this is a bug in iOS and not in securefs. The workaround is to disable the indexing of the Files app in Settings, Siri and Suggestions. The interesting part is the cause: a search indexer cannot read the contents of the encrypted files, so the search silently loses them.

The third is the GUI note. SiriKali is listed as a GUI frontend for securefs and for several other filesystems, and the README says this is informational only, that the author of securefs has never tried SiriKali or vetted its code. That is a stronger statement than a missing endorsement, and it is the right thing to know before you install a third party interface for your encrypted files.

The crash resistance section is cut off in the text available here, and it begins by saying that if securefs exits abnormally, or the computer suddenly powers down, the guarantees are limited. For a filesystem holding the only copy of something, that paragraph is the one to read in full.

Editorial conclusion

Adopt securefs when you want an encrypted directory that cloud sync tools can copy, when you need the choice between a fast lite format and a full format that hides the directory hierarchy, and when you accept FUSE as the mechanism and the swap warning as a rule. Do not adopt it as a full disk encryption replacement, since it protects a mounted directory rather than the device, and treat the SiriKali GUI mention as informational only, because the author states they have never tried or vetted that code. Before you mount anything, read the crash resistance section, disable or encrypt swap and hibernation, and decide between the formats deliberately, since the choice affects how the encrypted data looks to the sync tool.

Frequently asked questions

Official sources

1. Issues
2. netheril96/securefs on GitHub
3. README
4. Releases