[Bug]: invalid argument, permission denied when running containers with --userns=auto in rootful on FCOS #17171
Comments
|
have you tried the workaround suggested here: coreos/fedora-coreos-tracker#1305 (comment) ? |
|
@giuseppe yes ( does not work ), its a slightly different problem, in coreos/fedora-coreos-tracker#1305 no container can start, while I can start containers, but seems that attaching when running two same containers can cause these symptoms ( but again its failing only for one container, probably for the newer one ) |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@giuseppe @lukasmrtvy Any update on this one? |
|
@rhatdan same error in 4.4.1 ( from dmesg I also noticed there is another error ending with both related to attaching the container. Will try to do more investigation. |
|
@lukasmrtvy have you tried either deleting the underlying container image and pulling again or exporting the image, deleting and importing back again? The thread that @giuseppe mentioned had those workarounds added recently, after original one he referred to. These seem to fix the immediate issue though not the underlying cause for me. I have not found a pattern as to why it happens or how to reproduce this. This happened again to me but this time it was the container launched correctly a few times and then it did not (same podman version and os version between launches). The podman output is the same each time but dmesg output does seem to vary a bit for me. I have seen return code |
|
@ykuksenko thanks using ( podman.service is triggered by podman.socket, so this should work out of the box ): snippet from coreos/fedora-coreos-tracker#1305 (comment) and its working, at least I dont see any errors mentioned in this issue anymore. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
I think this has resolved itself, so closing. |
github-actions
bot
added
the
locked - please file new issue/PR
Issue Description
When running some ( probably the same ) containers with
--userns=autovia API ( rootful ), sometimes ( its not random pattern I believe ) I will getinvalid argumentandpermission deniederror, but just for only one container, the other will run correctly. ( My application is using http://podman.io/libpod/containers/{name}/attach endpoint for streaming logs ). I am trying with 4.4.0-dev on Fedora CoreOS. I do not have the reproducer yet but I will edit this ASAP once I figure out how to reproduce this problem.Related:
36.20220906.3.2, but can with36.20220820.3.0coreos/fedora-coreos-tracker#1305Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
Some containers are not running with --users=auto in rootful on FCOS.
Describe the results you expected
Some containers are running with --users=auto in rootful on FCOS.
podman info output
host: arch: amd64 buildahVersion: 1.29.0-dev cgroupControllers: - cpuset - cpu - io - memory - hugetlb - pids - misc cgroupManager: systemd cgroupVersion: v2 conmon: package: conmon-2.1.4-2.fc37.x86_64 path: /usr/bin/conmon version: 'conmon version 2.1.4, commit: ' cpuUtilization: idlePercent: 99.74 systemPercent: 0.07 userPercent: 0.19 cpus: 16 distribution: distribution: fedora variant: coreos version: "37" eventLogger: journald hostname: ip-10-1-36-183 idMappings: gidmap: null uidmap: null kernel: 6.0.12-300.fc37.x86_64 linkmode: dynamic logDriver: journald memFree: 63377928192 memTotal: 66354380800 networkBackend: netavark ociRuntime: name: crun package: crun-0.0-20230118104133.e6c1ca3.fc37.x86_64 path: /usr/bin/crun version: |- crun version UNKNOWN commit: 62fdf71b63c8026fc879bd1f6459bddb16599538 rundir: /run/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +LIBKRUN +WASM:wasmedge +WASM:wasmtime +YAJL os: linux remoteSocket: exists: true path: /run/podman/podman.sock security: apparmorEnabled: false capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: false seccompEnabled: true seccompProfilePath: /usr/share/containers/seccomp.json selinuxEnabled: true serviceIsRemote: false slirp4netns: executable: /usr/bin/slirp4netns package: slirp4netns-1.2.0-8.fc37.x86_64 version: |- slirp4netns version 1.2.0 commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383 libslirp: 4.7.0 SLIRP_CONFIG_VERSION_MAX: 4 libseccomp: 2.5.3 swapFree: 0 swapTotal: 0 uptime: 0h 36m 16.00s plugins: authorization: null log: - k8s-file - none - passthrough - journald network: - bridge - macvlan volume: - local registries: search: - docker.io store: configFile: /etc/containers/storage.conf containerStore: number: 2 paused: 0 running: 2 stopped: 0 graphDriverName: overlay graphOptions: {} graphRoot: /var/lib/containers/storage graphRootAllocated: 1098974756864 graphRootUsed: 8778694656 graphStatus: Backing Filesystem: xfs Native Overlay Diff: "true" Supports d_type: "true" Using metacopy: "false" imageCopyTmpDir: /var/tmp imageStore: number: 4 runRoot: /var/home/core transientStore: false volumePath: /var/lib/containers/storage/volumes version: APIVersion: 4.4.0-dev Built: 0 BuiltTime: Thu Jan 1 00:00:00 1970 GitCommit: "" GoVersion: go1.19.5 Os: linux OsArch: linux/amd64 Version: 4.4.0-devPodman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
Cloud:
OS:
Version:
Podman package from copr:copr.fedorainfracloud.org:rhcontainerbot:podman-next
Additional information
No response
The text was updated successfully, but these errors were encountered: