Error: writing blob: adding layer with blob “sha256:1f38867ae61659d2394ce2253fde6b112fd97f41ea5737405d1a1d1587767271”: processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 71873:0 for /opt/dev_ucx/MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64/DEBS/neohost-backend_1.5.0-102_amd64.deb): Check /etc/subuid and /etc/subgid if configured locally and run podman-system-migrate: lchown /opt/dev_ucx/MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64/DEBS/neohost-backend_1.5.0-102_amd64.deb: invalid argument): exit status 1
In the layer with ID f1313b11cc, a tgz file MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64.tgz is downloaded and extracted. This tar file contains two files with owner=71873; neohost-backend_1.5.0-102_amd64.deb and neohost-sdk_1.5.0-102_amd64.deb. Even though both files are removed in a later layer, 8bb8243025, rootless podman does not allow combining the layers because the owner uid of the two files is outside the maximum size of the user namespace.
This problem can be amended by increasing the maximum allowed user namespace in /etc/subuid. However, in my case this is not a viable option as I do not have root privileges on the server.
• Proposed resolution:
When unpacking MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64.tgz, add the flag --no-same-owner to the tar command, to extract all files as the root user.
Are you able to run this docker image after pull it in this way? Sorry but we didn’t verify podman in this way, assume you can manage all the dependencies.
In case you need compare the behavior in docker, below are the links for reference:
Unfortunately, I did not find anything in the document you linked to, that helps me with this particular problem.
The problem occurs only with that particular image: deepstream:6.2-triton. I do not have a problem with pulling or running other NVIDIA containers, and can utilize the GPU when doing so. For example, I can run the following command without issues:
As I described in my original post, the problem with deepstream:6.2-triton is that it contains layers where a few files have abnormal owner IDs. This could be easily fixed by rebuilding the image in a way such that the files in question get normal ownership. I proposed one way of doing that in the original post. However, this has to be done when building the original image on your side.