I don't think this is ISPConfig's fault, but something has changed in AlmaLinux 8.7 (and presumably other RHEL clones like Rocky Linux, Oracle Linux when they are released) and it has affected the way shell users work. I need help to track down what is causing this please. Expected Behaviour Before updating to 8.7 if you logged in as a shell user, you would get the shell username in the bash PS1 prompt, and scripts and cron tasks executed would be run as the shell user, not the webXX user. Actual Behaviour Now, after updating, if you log in as the shell user you receive a bash prompt displaying the webXX username instead, and all processes previously executed as the shell user instead run as the webXX user, including cron tasks. Symptoms Rootless container permissions are all messed up. Rootless containers rely on the subuid system and allocations defined in /etc/subuid. Files, volumes and storages that need to be available in a rootless container must be owned by the correct subuid in the range allocated to the parent userid. However the container is now attempting to run as the webXX user, not the shell user. The webXX user has a different subuid allocation to the shell user in /etc/subuid and therefore cannot access any volumes and storage layers created by the container when it previously ran under a different user. This gives plenty of permission denied type errors and the container fails to start. In addition as the shell user is now not available, it's not even possible to delete and recreate these files without root privileges. Our levels of "suspicious activity" are off the charts as our automated monitoring has detected that users are suddenly running completely "novel" processes, even though this is normal behaviour, the user has just changed. We are also having problems with systemd --user being unable to find unit files, I think that's because the home directory (and therefore the location of user unit files) is different because the user is different. Further Information You don't need to reboot to get this new behaviour, so it's probably not the kernel update. It seems to be related to the order of users in /etc/passwd. Normally the webXX user comes before the shell user in /etc/passwd because a site must be created before the shell user. If I swap the order of the users so that the shell user comes first, then I get the correct bash prompt again, however the container and systemd stuff above is still broken. So it seems like suddenly the order of /etc/passwd matters. However it shouldn't, as all the webXX users have /bin/false as their shell, so login as webXX shouldn't be possible.