[Podman] Rootless container with --uidmap: root loses privileges inside the container

I've had quite a lot of success with running rootless Podman containers in a Ubuntu 22.04 Vagrant box. They're able to connect to services running on the host, and by using the --uidmap parameter, I've been able to make the container user write to bound volumes from the host with the privileges of the non-root host user that is running the service. One last hurdle remains: I have a container running as a systemd user service as a non-root user, but internally the container runs as root. I'm using --uidmap 0:0:1 so that when the container's root user writes to bound host volumes, on the host they appear to have been created by the non-root service user. What surprised me is that when this UID mapping is in place, the root user seems to lose root privileges inside the container. I was trying to install redis-tools to debug a Redis connection issue inside the running container, and ran 'apt update' as the container root user. This failed with errors: E: setgroups 65534 failed - setgroups (22: Invalid argument) E: setegid 65534 failed - setegid (22: Invalid argument) E: seteuid 100 failed - seteuid (22: Invalid argument) rm: cannot remove '/var/cache/apt/archives/partial/*.deb': Permission denied Reading package lists... Done W: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (22: Invalid argument) W: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (22: Invalid argument) E: setgroups 65534 failed - setgroups (22: Invalid argument) E: setegid 65534 failed - setegid (22: Invalid argument) E: seteuid 100 failed - seteuid (22: Invalid argument) E: Method gave invalid 400 URI Failure message: Failed to setgroups - setgroups (22: Invalid argument) E: Method gave invalid 400 URI Failure message: Failed to setgroups - setgroups (22: Invalid argument) E: Method http has died unexpectedly! E: Sub-process http returned an error code (112) If I run the container without the --uidmap parameter, this command starts working again, but naturally I lose the user mapping I described above. Honestly, I'm probably able to rebuild the image that the container uses in such a way that its application runs as a non-root user (and then I'll just use e.g. --uidmap 1000:0:1, which I've found to work elsewhere), but I'm clearly missing something about the UID mapping functionality with an in-container root user, because I don't understand what about it is causing these errors. Any ideas?