`/run/media/$USER/external_drive` owned by `nobody` inside containers

[Guillawme]

Issue Description

On Fedora Silverblue 43, connecting an external storage device gets it mounted under /run/media/$USER/drive_name and this directory is owned by the logged-in account. This always happens correctly on the host system.

However, from inside a toolbx container (which appears to use podman under the hood), different behaviors are observed depending on whether the drive was mounted before or after the container started:

• If the external drive was mounted before the toolbx container started, it looks correctly owned by the logged-in account from inside the container. This is the expected behavior since toolbx is meant to provide a mutable CLI environment on immutable systems: external drives are meant to be accessible from inside a running toolbx container.
• If the external drive was mounted after the container started, it looks owned by nobody:nobody from inside the container and the logged-in user has no permissions on this path.

Either way, from the host system the external drive's mount point appears correctly owned by the logged-in account.

I believe this is the same problem as described in #14183. It affects toolbx containers too, as reported in containers/toolbox#1073.

Steps to reproduce the issue

Steps to reproduce the issue from Fedora Silverblue 43

Preparation

Set up a toolbx container: toolbox create.

Trigger the bug

1. Start the container: toolbox enter.
2. Connect the external drive.
3. Try to navigate to it or list its contents from the container: ls /run/media/$USER/external_drive
4. Check which account owns the path to the drive: ls -l /run/media/$USER

Describe the results you received

Result of ls /run/media/$USER/external_drive:

ls: cannot open directory '/run/media/$USER/external_drive/': Permission denied

Result of ls -l /run/media/$USER:

drwx------. 2 nobody    nobody    40 Apr  8 21:17 external_drive/

Describe the results you expected

The external drive should be accessible from inside the toolbx container, and owned by the logged-in account (as it is on the host system):

drwxr-xr-x. 2 $USER    $USER    40 Apr  8 21:17 external_drive/

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: 98.5
    systemPercent: 0.37
    userPercent: 1.13
  cpus: 24
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: silverblue
    version: "43"
  emulatedArchitectures:
  - linux/arm64
  - linux/arm64be
  eventLogger: journald
  freeLocks: 2047
  hostname: fw13
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.19.10-200.fc43.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 10000060416
  memTotal: 24954417152
  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/1000/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/1000/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: 8589930496
  swapTotal: 8589930496
  uptime: 2h 25m 21.00s (Approximately 0.08 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: /var/home/guillaume/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/guillaume/.local/share/containers/storage
  graphRootAllocated: 997409685504
  graphRootUsed: 118919741440
  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: 1
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /var/home/guillaume/.local/share/containers/storage/volumes
version:
  APIVersion: 5.8.1
  BuildOrigin: Fedora Project
  Built: 1773187200
  BuiltTime: Wed Mar 11 01: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

None

Upstream Latest Release

Yes

Additional environment details

Nothing special, an up-to-date Fedora Silverblue 43:

$ rpm-ostree status
● fedora:fedora/43/x86_64/silverblue
                  Version: 43.20260407.0 (2026-04-07T00:29:03Z)
               BaseCommit: ac6012e4128c63e531b18a2f8172b0ad5704112c0048efefe7ba4f59c5c99580
             GPGSignature: Valid signature by C6E7F081CF80E13146676E88829B606631645531
      RemovedBasePackages: firefox firefox-langpacks 149.0-4.fc43
          LayeredPackages: ghostty restic

Additional information

It seems pretty clear that the order of operations is the problem because:

1. If I connect the external drive first, then start the toolbx container, I can access the drive from the container.
2. If I then keep the container running, disconnect and reconnect the drive, and try again, then the container sees the drive as owned by nobody and I don't have any permission on the drive from inside the container.
3. If I now keep the drive connected and mounted on the host system, stop the container and start it again, then the container sees the drive as owned by the logged-in account again.

[baude]

can you make a reproducer that does not use toolbox ?

[Guillawme]

Not right now because I don't know how to use podman, so it will take me some time to learn it (if I even find time to get to it). But this comment from @debarshiray on the older issue #14183 suggests a podman command. In fact, I would have simply posted to #14183 if it had not been automatically closed.

[Guillawme]

Not sure if this will help you, but I could in fact find the podman command run by toolbx when inspecting the process in system monitor:

podman \
  --log-level error \
  exec \
  --detach-keys \
  --env=COLORTERM=truecolor \
  --env=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus \
  --env=DESKTOP_SESSION=gnome \
  --env=DISPLAY=:0 \
  --env=HISTCONTROL=ignoredups \
  --env=HISTSIZE=1000 \
  --env=HOME=/var/home/guillaume \
  --env=LANG=en_US.UTF-8 \
  --env=SHELL=/bin/bash \
  --env=SSH_AUTH_SOCK=/run/user/1000/gcr/ssh \
  --env=TERM=xterm-256color \
  --env=TOOLBOX_PATH=/usr/bin/toolbox \
  --env=USER=guillaume \
  --env=WAYLAND_DISPLAY=wayland-0 \
  --env=XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.91RHN3 \
  --env=XDG_CURRENT_DESKTOP=GNOME \
  --env=XDG_DATA_DIRS=/var/home/guillaume/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/ \
  --env=XDG_MENU_PREFIX=gnome- \
  --env=XDG_RUNTIME_DIR=/run/user/1000 \
  --env=XDG_SESSION_CLASS=user \
  --env=XDG_SESSION_DESKTOP=gnome \
  --env=XDG_SESSION_TYPE=wayland \
  --env=P11_KIT_SERVER_ADDRESS=unix:path=/run/user/1000/toolbox/pkcs11 \
  --interactive \
  --preserve-fds 0 \
  --tty \
  --user guillaume \
  --workdir /var/home/guillaume \
  fedora-toolbox-43 \
  capsh \
  --caps= -- \
  --login -c exec "$@" bash

I assume, but have not tested, that it would work the same as what I described above: mount the external drive, run a container with a similar command (username and path need to be adjusted), see if the external drive is accessible from inside the container. And do the same test with the drive mounted after the container is started.

[Luap99]

You can use any image and just need to mount /run/media AFAICT.

I guess this has something to do with the mount propagation, the mount does propagate into the podman userns (i.e. I see it with podman unshare), but not into the container despite using -v /run/media:/run/media:rshared.

The permissions error is misleading, it only happens because the underlying mount point directory that is overmounted is created as root (which is not mapped into the container namespace and hence shown as nobody)

@giuseppe Any ideas why this mount does not propagate even though the mount propagation seems to be shared everywhere?