rootless podman bind mount permission denied when selinux enabled

[jstebbins]

Issue Description

I have a podman quadlet that worked just prior to a recent system update. After the update, a bind mounted volume is inaccessible if selinux is enable. If I run setenforce 0, the mount becomes accessible.

Steps to reproduce the issue

Steps to reproduce the issue

1. Start the quadlet systemctl --user start jellyfin.service
2. podman exec -it <id> bash
3. ls -l /jelly

Describe the results you received

The above results in permission denied.

If I disable selinux with setenforce 0 I get the expected directory listing.

Describe the results you expected

Expected a directory listing

podman info output

host:
  arch: amd64
  buildahVersion: 1.43.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.2.1-2.fc43.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.2.1, commit: '
  cpuUtilization:
    idlePercent: 96.55
    systemPercent: 1.47
    userPercent: 1.98
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: workstation
    version: "43"
  emulatedArchitectures:
  - linux/arm
  - linux/arm64
  - linux/arm64be
  - linux/loong64
  - linux/mips
  - linux/mips64
  - linux/ppc
  - linux/ppc64
  - linux/ppc64le
  - linux/riscv32
  - linux/riscv64
  - linux/s390x
  eventLogger: journald
  freeLocks: 2045
  hostname: tworker
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 589824
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 589824
      size: 65536
  kernel: 6.19.11-200.fc43.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 268099584
  memTotal: 16523198464
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    defaultNetwork: podman
    dns:
      package: aardvark-dns-1.17.0-1.fc43.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.17.0
    package: netavark-1.17.2-1.fc43.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.17.2
  ociRuntime:
    name: crun
    package: crun-1.27-1.fc43.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.27
      commit: a718a92cc9a94955a5a550b6fdec1378c247ec50
      rundir: /run/user/1001/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20260120.g386b5f5-1.fc43.x86_64
    version: |
      pasta 0^20260120.g386b5f5-1.fc43.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1001/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-3.fc43.x86_64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.9.1
      SLIRP_CONFIG_VERSION_MAX: 6
      libseccomp: 2.6.0
  swapFree: 8588677120
  swapTotal: 8589930496
  uptime: 1h 20m 46.00s (Approximately 0.04 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /home/jack/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jack/.local/share/containers/storage
  graphRootAllocated: 510405902336
  graphRootUsed: 34054492160
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 16
  runRoot: /run/user/1001/containers
  transientStore: false
  volumePath: /home/jack/.local/share/containers/storage/volumes
version:
  APIVersion: 5.8.1
  BuildOrigin: Fedora Project
  Built: 1773187200
  BuiltTime: Tue Mar 10 18:00:00 2026
  GitCommit: c6077f645788743258a1a749f8005b4fb3cbe533
  GoVersion: go1.25.7 X:nodwarf5
  Os: linux
  OsArch: linux/amd64
  Version: 5.8.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Distro: Fedora 43

Additional information

Here is the quadlet I'm using. This quadlet worked prior to a system update I performed today.
I've also tried adding 'Z' and 'z' to the Volume options. None work.
/jellyfin is an NFS mounted filesystem

[Unit]
Description="Jellyfin media server"

[Container]
AddDevice=/dev/dri:/dev/dri
AutoUpdate=registry
ContainerName=jellyfin
Image=docker.io/jellyfin/jellyfin:latest
Network=slirp4netns:port_handler=slirp4netns
PublishPort=8096:8096/tcp
UserNS=keep-id
Volume=jellyfin-config.volume:/config
Volume=jellyfin-cache.volume:/cache
Volume=/jellyfin:/jelly:ro,slave

[jstebbins]

Adding a bit of interesting information...

When I get the permission error, there are no AVC errors. I.e. ausearch -m avc shows nothing.

As an experiment, I tried adding SecurityLabelDisable=true to the quadlet. This "fixes" the problem. But it seems like something funky is happening given the lack of AVC errors when the permissions error occurs.

[jstebbins]

Adding more to this, the NFS filesystem I'm using is automounted. It turns out that adding SecurityLabelDisable=true only "works" if the filesystem is already mounted when starting the quadlet. If it is not already mounted, I get an Operation not permitted error when it attempts to access (and mount) the filesystem. Again, this happens with no AVC errors showing. But now if I add Z to the volume options, it successfully automounts the filesystem.

None of this was necessary prior to a system update I performed the day this started happening. I would like to understand what changed and why if it's an intentional change in behavior.

[giuseppe]

try enabling dontaudit rules to be logged as well:

semodule -DB

Then try again to restart the container. You'll likely find the reason in the log this time. Once you figure out what is happening, disable dontaudit rules to be logged to avoid excessive logging with semodule -B

[giuseppe]

have you tried that? Got any AVC error?

[jstebbins]

Sorry for the late response. I'm traveling, so can't check this till next week.

[jstebbins]

After running semodule -DB I see the following
type=AVC msg=audit(1779389512.309:901): avc: denied { read } for pid=313101 comm="ls" name="/" dev="autofs" ino=1473896 scontext=system_u:system_r:container_t:s0:c649,c802 tcontext=system_u:object_r:autofs_t:s0 tclass=dir permissive=0

This happens with and without 'Z' added to volume args. The only way I have found to force this to work is to disable selinux or also add SecurityLabelDisable=true to the quadlet.

[Ghoelian]

For anyone coming across this but is using a compose file, you can work around the issue by adding the following to your service:

security_opt:
  - "label=disable"

[Clancy508]

The issue you're probably facing is extended attributes - NFS mounts usually can't store extended attributes which include SELinux labels. That means when you mount the volume with :z Podman tries and fails to label the filesystem as container_file_t, and because it's unlabelled SELinux still denies access. You can test this pretty easily by booting the container with the :z label and, while it's running, on the host run ls -Z on the mount directory, if labels are being applied it should be listed with something like system_u:object_r:container_file_t:s0, if it's not being labelled correctly it'll show ?. You can enable xattrs for NFS mounts which may be enough to fix this if this is the problem, otherwise you can use Audit2Allow on the AVC logs to create a SELinux policy to permit NFS access (that AVC message in your last post for instance is saying that container processes aren't allowed to access autofs mounts, when you add Z Podman is presumably able to relabel the mount directory which then lets it trigger the automount, but the files/folders inside it are still not labelled correctly)

Side note, the difference between z and Z is that capital Z tells Podman to label the mount for exclusive access by only a single container, while lowercase just labels it container_file_t, they should be identical for a single container but Z will prevent other containers from sharing the mount.

[jstebbins]

I'm not seeing it get set to system_u:object_r:container_file_t:s0 (it doesn't change when I start the container). But it is not ? either.

$ ll -aZ /jellyfin/
total 15
drwxr-xr-x. 3 root root system_u:object_r:autofs_t:s0   0 May 26 13:44 .
dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0   200 Dec 21 10:51 ..
drwxr-xr-x. 7 root root system_u:object_r:nfs_t:s0      7 Jul 29  2025 media

Your theory also doesn't explain why it was working until I did a system update on Apr 8.