EncFS: The 20-Year-Old Encrypted Filesystem That Just Got Rewritten in Rust
Hook
One of Linux’s earliest FUSE filesystems just got a Rust port after two decades of C++ service—but its original author now recommends you use something else for new projects.
Context
Back in 2003, encrypting files on Linux meant wrestling with kernel modules that broke with every system update. When FUSE (Filesystem in Userspace) emerged, Valient Gough created EncFS as a userspace alternative that could survive kernel upgrades without recompilation. Unlike full-disk encryption, EncFS operates at the file level: it translates filesystem operations on a virtual mount point into encrypted operations on an underlying directory. Each plaintext file becomes an individually encrypted file with an obfuscated name, stored in a normal directory on your disk.
This architecture made EncFS particularly attractive for cloud storage scenarios. When you modify a file in Dropbox or Google Drive, only that file needs to re-sync. With full-disk encryption or block-level systems, changing one byte can trigger cascading updates across multiple blocks. EncFS’s file-level granularity meant your encrypted files could live in ~/Dropbox/encrypted and sync efficiently as independent units. The filesystem matured over the years, serving users who needed encryption without the overhead of mounting entire encrypted volumes. Now, 23 years after its initial release, the project has been ported to Rust while the original C++ code has been retired. The Rust implementation maintains compatibility with decades-old encrypted data, though it’s currently in alpha status.
Technical Insight
EncFS uses a two-directory model that’s simple but effective. One directory stores encrypted files with scrambled names; the other is a FUSE mount point where you interact with plaintext. When you write to ~/mount/document.txt, EncFS encrypts the content and filename, storing something like ~/encrypted/aB3xK9pL2mN on disk. The new Rust implementation introduces a V7 configuration format with Argon2id key derivation and AES-GCM-SIV block encryption, addressing long-standing cryptographic weaknesses in older configs.
Creating and mounting a new filesystem follows a two-step pattern:
# Step 1: Initialize the encrypted directory
mkdir -p ~/encrypted
encfsctl new ~/encrypted
# Prompts for password, creates .encfs7 config
# Step 2: Mount it
mkdir -p ~/mount
encfs ~/encrypted ~/mount
# Access plaintext files at ~/mount
# Encrypted storage lives in ~/encrypted
# When done:
fusermount -u ~/mount # LinuxUpgrading from legacy V4/V5/V6 configs is straightforward: encfsctl passwd --upgrade ~/encrypted converts to V7 format while preserving your encrypted data. The old config file remains untouched, so you can roll back if needed.
The most architecturally interesting feature is reverse encryption mode via the encfsr binary. Instead of mounting encrypted data as plaintext, it does the opposite: your plaintext files stay on disk, and the mount point exposes an encrypted view of them. This is read-only by design, intended for backup workflows where you want to sync encrypted copies to untrusted storage without ever storing plaintext there:
# Plaintext lives in ~/Documents
# Create a deterministic config (no per-file IV headers)
encfsctl new --no-unique-iv ~/Documents
# Mount encrypted view at /mnt/encrypted_view
encfsr ~/Documents/.encfs7 ~/Documents /mnt/encrypted_view
# Now rsync or rclone from /mnt/encrypted_view to cloud storage
# The backup sees only encrypted files and obfuscated names
rsync -av /mnt/encrypted_view/ user@backup:/encrypted_backup/
fusermount -u /mnt/encrypted_viewThe --no-unique-iv flag during config creation is critical for reverse mode. It makes encryption deterministic (same plaintext always produces the same ciphertext), enabling deduplication and incremental backups. Without it, per-file IV headers would cause the encrypted view to change on every mount, defeating the purpose.
One notable quirk for Dropbox users: the README explicitly warns to disable External IV chaining with encfsctl new --no-chained-iv due to pathological interactions with Dropbox’s rename detection. IV chaining mode can trigger unnecessary re-uploads when files are moved or renamed, as the cryptographic chain affects neighboring files. This is the kind of battle-tested operational knowledge that only comes from 20 years of real-world usage.
The Rust port leverages modern FUSE bindings and memory-safe idioms. Encrypted volumes created in 2003 appear to remain accessible in 2026, suggesting careful attention to format compatibility during the migration.
Gotcha
EncFS appears to have significant metadata leakage by design based on its file-level encryption architecture. Because it encrypts individual files, your encrypted directory likely reveals the directory structure, file sizes, modification times, and approximate file count. An attacker with access to ~/encrypted can’t read your content, but they could potentially see you have a 47KB file modified last Tuesday in a subdirectory three levels deep. If you need to hide this metadata, EncFS may not be the right tool—consider block-level alternatives like CryFS that encrypt entire filesystem structures into uniform chunks.
The Rust port is functional but explicitly labeled alpha quality as of February 2026. The original author recommends maintaining separate backups for any data stored in it. More importantly, Valient Gough himself suggests using GoCryptFS for new encrypted filesystem setups. EncFS is primarily maintained for legacy data access—people who encrypted files in 2005 and still need to read them today. This honest assessment is rare in open source, and you should take it seriously. The project works, it’s maintained, but it’s not the cutting edge anymore.
Reverse mode requires V7 configs and won’t work with older formats, so if you’re hoping to create encrypted backup views of existing EncFS volumes, you’ll need to upgrade first. The --no-unique-iv requirement also means you’re trading deterministic encryption (necessary for deduplication) against per-file uniqueness guarantees.
Verdict
Use if: You have existing EncFS-encrypted data from the past two decades and need reliable access to it, or you specifically need file-level encryption that syncs efficiently with cloud storage services like Dropbox where individual file changes matter. The reverse encryption mode is genuinely clever for creating encrypted backups of plaintext directories without storing plaintext remotely. It’s also worth considering if you’re maintaining legacy systems where EncFS is already deployed and working.
Skip if: You’re starting a new encrypted filesystem from scratch—the original author recommends GoCryptFS instead, and that recommendation carries weight. Skip it if metadata leakage (visible file sizes, directory structure, modification times) is a concern for your threat model. Skip it if you need production-grade stability today, as the Rust port is still alpha quality. Finally, skip it if you want active feature development; EncFS is in maintenance mode, kept alive primarily for backward compatibility with decades of encrypted data.
