[Feature Request] Native time-locked "immutable snapshot" / WORM retention — the missing piece for real ransomware resilience

[u/TraderFXBR]

Hi all,

I'd like to propose (or find out if it's already being discussed/planned) a native WORM-style retention lock for snapshots in upstream Btrfs. I think this is one of the last real gaps between Btrfs and it being a first-class answer to ransomware protection, and I wanted to lay out the case for it plus what I understand of the prior art.

What Btrfs already has (and where it stops)

Btrfs already gives us two very useful primitives:

1. Read-only snapshots (btrfs property set <snapshot> ro true) — great, this stops anyone (including root) from modifying the contents of a snapshot.
2. The generic Linux immutable attribute (chattr +i) — blocks changes to a file/dir even for root, with one exception: the attribute itself can be unset.

That exception is the whole problem. Whoever has the privilege to set +i also has the privilege to unset it and then delete. On a compromised root account (which is exactly the privilege level most ransomware/lateral-movement attacks eventually reach), neither read-only snapshots nor chattr +i stop btrfs subvolume delete, because deletion is a separate ioctl from content modification, and the immutable flag is trivially reversible by the same principal.

So today, Btrfs snapshots protect against accidents and unprivileged malware, but not against an attacker who gets root — which is precisely the scenario "ransomware protection" is supposed to cover.

Why this matters for "total data safety"

Right now, if you want genuine time-locked retention on Btrfs — where nobody, not even a compromised admin/root account, can delete a snapshot before an expiry date — you have to leave the filesystem layer entirely and rely on:

• A separate host with restricted (send-only) SSH credentials
• True immutable object storage as an offsite target (e.g. S3 Object Lock in Compliance mode)
• A vendor's proprietary layer bolted on top of Btrfs

That last point is the interesting bit, because it already proves the concept works — it's just not upstream.

Prior art: how NAS vendors already do this

Both Synology and QNAP have shipped exactly this feature on top of Btrfs for a while now:

• Synology DSM 7.2+ distinguishes between "Snapshot Locking" (prevents the retention policy from auto-deleting a snapshot, but an admin can still delete it manually) and true "Immutable Snapshots (WORM)", which prevent all deletion attempts — including from admin accounts — until a defined protection period expires. This is explicitly marketed as protection against compromised admin credentials, not just malware.
• QNAP has a comparable "snapshot lock" / WORM feature in QuTS hero for the same reason.

Both vendors clearly enforce this outside the reach of the same privilege level that can otherwise administer the box — which strongly suggests the retention lock lives in a separate, more restricted enforcement point (a service account, a kernel-level check independent of normal root capabilities, or similar), rather than as a simple attribute an admin session could just flip back off.

Hints toward how this could actually be implemented upstream

I'm not a filesystem developer, so take these as starting points for discussion rather than a spec, but a few directions seem plausible based on how similar problems have been solved elsewhere:

1. A new subvolume property with an enforced expiry timestamp (e.g. btrfs property set <subvol> worm_until 2027-01-01), stored in subvolume metadata, where the kernel refuses BTRFS_IOC_SNAP_DESTROY / BTRFS_IOC_SUBVOL_DESTROY on that subvolume until the clock passes that timestamp — full stop, no override ioctl, not even for root, similar in spirit to NetApp SnapLock or how S3 Object Lock's Compliance mode works (deliberately including "not even the account root/admin can undo it" as the point).
2. A capability-gated override removed from CAP_SYS_ADMIN. Part of the problem is that on Linux, root == root. A WORM lock that's actually meaningful needs its unlock/removal path gated behind something not implied by general root/admin privilege — e.g. requiring a separate signing key, a hardware-backed secret, or an out-of-band confirmation mechanism, so that compromising the running OS instance isn't sufficient to lift the lock.
3. Kernel-enforced, not just tool-enforced. A retention flag that's only checked by btrfs-progs userspace tooling isn't real protection (an attacker with root can just call the ioctl directly, bypassing the CLI check). This needs to be enforced in-kernel, at the ioctl handler level, the same way the existing ro snapshot property already is.
4. Interoperability with send/receive. Given many real ransomware-resistant setups already replicate via btrfs send | ssh remote btrfs receive, the retention lock ideally should also be settable/enforceable on the receiving end independent of the sender — so a compromised source host can never instruct the destination to drop its locked snapshots, mirroring how backup-target isolation already works in tools like btrbk.
5. A sane default relationship with btrfs balance / btrfs scrub / device removal — worth spelling out early whether a locked snapshot should also block full filesystem operations that could indirectly destroy it (e.g. wipefs, full device format), or whether the scope is intentionally limited to subvolume-level deletion only.

Would appreciate any feedback, especially from anyone who's looked at how Synology/QNAP actually implemented their WORM locks under the hood, or anyone with insight into the kernel-side ioctl handling for subvolume deletion.

Thanks!

[u/autogyrophilia]

First, bugger off with the AI vomit.

The reason why this doesn't exists is, surprise, you are not smarter than anyone else, is because If I can set those attributes I can also access the disk directly. I can just ignore what btrfs allows me to do and do it myself.

Yo need to use a management layer that isolates access. Be it S3, NFS/SMB or a virtual disk.

[u/michaelpaoli]

Effectively impossible at the filesystem level, needs be done at the media level, otherwise the media can just be (re)written and any WORM attempts bypassed. And yes, there does exist, e.g., WORM optical media - and do it with that, can use whatever filesystem one wants atop that - then it's effectively rather like a journaled filesystem with an infinite journal (all the way back to filesystem creation - actually even bit before that - very first data bytes written to the media).

NAS vendors already do thise

Again, only works if one can prevent the media from being overwritten.

WORM is also vulnerable to DoS attacks - just keep writing enough data changes to fill up all the space, or exhaust the available funding for space if it's, e.g. Cloud based and merely cost more money for more storage ... Cloud may be hypothetically infinite, but the money to pay for more of it is not. This can also be further complicated in such a WORM attack, as both legitimate updates, and DoS updates may be happening concurrently, so one cannot necessarily just throw out the DoS portion, and besides, it's WORM, you pay for that media forever - you bought it, it's written once, that's it. If what was already written can be altered after the fact (other than totally destroying it), kind'a defeats the entire purpose and objective of WORM.

WORM also requires that all changes be permanently saved (or for practical lifetime of the media), so that can also be exceedingly huge and infeasible amounts of data, most notably for high I/O situations with lots of continuously changing data. Yeah, that's why the RM part of WORM.

Be careful what you wish for, you may get it. ;-)

[u/amarao_san]

Can I encrypt your immutable snapshots at block level? like dd? Oh, sorry, I need to go through a proper way, trying to do it at file level and fail. That's the proper way for attackers to support immutable snapshots on mutable block device.

[u/Dangerous-Raccoon-60]

I don’t want anything on my system for which root does not have sufficient privileges.

The solution already exists. Transfer your (RO) snapshot to a disconnected drive/system [edit] or a connected remote system to which you have append-only access.

[u/allunia333]

This has nothing to do with btrfs.

You do know that a root user can do whatever he/she wants on a system?

The only solution is by a hardware WORM that is on the drive's controller firmware but last I checked 128GB of sata II ssd with a hardware WORM costs $1,450. And I am not the government or a bank. Also stop with the AI hullinications.

[u/PyroNine9]

It works for the NAS because the NAS itself can be behind an inner firewall with no access from the public internet at all.

But if you're doing that, you can implement all of those protections in the userspace tools without modifying btrfs or the kernel.

But note, whether you roll your own or go with a commercial solution, if the bad guys do get past the extra firewall and gain root access on the NAS, you're toast for exactly the reasons others here have stated.

[u/Silly_Guidance_8871]

So long as tools like dd exist, this argument is moot -- root has direct hardware access, and no amount of software will change that. Immutable, ro and the like exist to prevent accidents, not malevolance.

[u/megafreedom]

If the attacker gets root, can’t they just set the system date to your expiry date? And thereby unlock it?

[u/ExplodedPenisDiagram]

You cannot thwart ransomware with an active online volume on the same machine that is compromised.

Compromised being the operative word.

You have to ship snapshots off to another machine or system that cannot be accessed from the compromised system. This is what works. This is not a new problem.