When the tmpfiles rules are changed, NixOS should automatically restart systemd-tmpfiles-resetup.service which runs systemd-tmpfiles --create --remove --exclude-prefix=/dev. Check whether this service properly triggers upon activation.
You said you use this rule to modify the file permissions which implies the file already exists; who creates the file? That’d be the best place to set the policy for the file’s permissions.
You might also simply be running into a race condition where the file is created (or re-created) after the systemd-tmpfiles-resetup.service runs.
We’re not talking about systemd here. This is systemd-tmpfilesd which is an entirely separate program and does not share state with systemd. As far as it’s concerned, it doesn’t care whether systemd (PID1) is present or not.
Contrary to popular belief, the systemd project is not a monolith.
Did you activate a generation where the tmpfiles rules differ from the previous generation? Resetup only gets started in that specific case.
You will need to figure this out. It’s likely the crux.
Though note that modification is not the important bit but explicit direct metadata modification or implicit indirect metadata modification (by replacing the file(=inode) with an entirely new one).
Have you checked in with upstream about this?
Whenever one of these services is started:
systemd-tmpfiles-setup.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup-dev-early.service
systemd-tmpfiles-resetup.service
The first three should only start once. The last is started as described above.
Another option you may want to consider is to change the umask of k3s which affects the permissions it’ll create new files with. Though this affects all files it writes, so it might also affect files other than this config file.
Yet another option (though I personally don’t like it) could be to use ACLs. Though again, if the file is deleted and re-created, they likely won’t help you either.