BTRFS subvolume permissions change after reboot!

[snovotill]

My root filesystem is BTRFS, and I've mounted a BTRFS subvolume at /srv.
I can change permissions on the mounted subvolume to 2770 but they revert after every reboot.
I have NO HAIR LEFT so please help if you know the secret.

My /etc/fstab on Debian Trixie:

UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 / btrfs subvol=@ 0 0
UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /home btrfs subvol=@home 0 0
UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /srv btrfs subvol=@srv 0 0
UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /std btrfs subvol=@std 0 0

Thanks =)

[snovotill]

This is weird work-around: If I delay mounting of the /srv subvolume until after multi-user.target via the fstab entry below, then permissions are NOT lost and everything works as expected. Could this have something to do with polkit or apparmor? Might one of these have the audacity to mess with my personally tailored permissions?

Here is the ferocious fstab entry that "works around" my problem:

UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /srv btrfs nofail,x-systemd.requires=multi-user.target,subvol=@srv 0 0

Now my 2770 pernissons survive the reboot

[pbear]

When I think of all the fun I miss by sticking with boring old ext4, I try not to be bitter.

[snovotill]

I have eliminated apparmor and polkit from the list of possible suspects, by masking both unit-files and confirming that the problem still persists.
I have also confirmed that the problem remains mitigated even by delaying only to basic.target.
I also ran auditd against the folder attributes and no culprits showed up, at least from the point where auditd starts.

This makes me think it is a BTRFS bug, ...still trying to get to the bottom of it.
I gave up because my workaround (prior post) works perfectly.

@pbear BTRFS is great these days. It has saved my ass many times and is super convenient.