From the new docs, > The primary usecase for this option is to automatically remove files and directories that originally have been created on behalf of an ins

From the new docs, > The primary usecase for this option is to automatically remove files and directories that originally have been created on behalf of an installed packaged at package removal time. > Warning! This is is usually not the command you want! In most cases --remove is what you are looking for These seem like good responses, reasonable safeguards & documentation additions. It also no longer runs without a specific config saying what tmpfiles to manage. This is scary & annoying, but it just seems like so much manufactured outrage & FUD from people. I agree that it's a bad look for systemd to close discussions so soon, but they also were on it & resolving it quite satisfactorily with due haste. (Well, I guess bluca's initial response was a strong rebuff, but that did get re-steered.) It would be lovely to get a better picture of how all the pieces slotted together to make this issue possible. It seems like maybe one system is trying to setup subvolumeable quotas for /home in some cases and that somehow triggered this? I feel like the excellent Dynamic Users feature would likely somehow be involved here, but unclear. https://0pointer.net/blog/dynamic-users-with-systemd.html https://0pointer.net/blog/dynamic-users-with-systemd.html