We use btrfs extensively for its wonderful snapshotting capabilities. But recently, and on only one system, while purging old snapshots, I began to receive the following error:
btrfs subvolume delete ...
ERROR: Could not destroy subvolume/snapshot: Operation not permitted
WARNING: deletion failed with EPERM, send may be in progress
There are numerous reasons why deleting a btrfs snapshot might fail; subvolumes present, any locked file on the volume to name just a couple. NOTE: "ro" property on a snapshot volume should NOT by itself prevent deletion. But this turned out to be something I have never encountered.
After much investigation, I discovered the snapshots for the last week all had the "immutable" attribute set.
lsattr <snapshot folder>
---------------------- ./221104
---------------------- ./221105
---------------------- ./221106
---------------------- ./221107
----i----------------- ./221108
----i----------------- ./221109
----i----------------- ./221110
----i----------------- ./221111
----i----------------- ./221112
Since all of the snapshots were created with the "ro" property set, simply executing a
chattr -i <snapshot>
results in
chattr: Read-only file system while setting flags
The snapshots "read-only" property must be set to false before you can change attributes. I did this and the snapshot deletion then succeeded but all new snapshots were still being created with the "i" attribute!
"Well, there's your problem..."
Turns out the mounted subvolume the snapshots are created from had the "immutable" attribute set by mistake while hardening mount points on the root file system.
Setting "immutiable" on your mount points is good practice and ensures the folder (and therefor your root filesystem) cannot be filled with junk should the volume fail to mount.
But if already mounted, the "i" flag gets applied, not to the folder, but to the mounted btrfs volume. And all subsequent snapshots then will share the "immutable" attribute.