Slightly misleading error message on missing user session, not missing subuid/subgid

[danishprakash]

When a user runs rootless podman without a proper login session, image pull fails with:

unpacking failed (error: exit status 1; output: 
potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): 
Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/gshadow: invalid argument)

Even though it says "potentially", we can perhaps improve the error message in cases where the subuid/subgid mappings exist for the user. This happens when fchownat fails with EINVAL:

container-libs/storage/pkg/chunked/filesystem_linux.go

Lines 175 to 177 in e70c309

	if errors.Is(err, syscall.EINVAL) {
	return fmt.Errorf(`potentially insufficient UIDs or GIDs available in the user namespace (requested %d:%d for %s): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": %w`, uid, gid, path, err)
	}

We could check for a user session similar to what c/common does(bus check) before printing an error message that instead suggests running loginctl enable-linger <uid> as the fix.

[giuseppe]

why does the user session affect that? As long as you are running with the correct uid:gid, then you can use newuidmap and newgidmap

[Luap99]

right, the files are static and not depended on systemd so I see no relation to the user session.

Generally speaking even the error message as is already seems a bit optimistic, we are deep in library code that can be reached from many tools, buildah, skopeo, cri-o, etc... so suggesting a podman command here seems strange

[danishprakash]

I may have landed on an incorrect assumption, but I still can't seem to figure out why an EINVAL on fchownat was encountered when /etc/subuid and /etc/subgid were correctly configured for that new user (without a proper login session). A subsequent loginctl enable-linger .. fixed the problem, which led me to assume that perhaps the mappings were not set right inside the user namespace?

so suggesting a podman command here seems strange

Agreed, we can drop the podman command from that error message.

[giuseppe]

is it something you can reproduce or did it happen just once?