FUSE in rootless, unprivileged podman

# Question Is adding CAP_SYS_ADMIN still the only way to get fuse working inside a rootless container (with either native overlay or fuse-overlayfs/other methods)? ---------- # Examples ## Podman in podman This example from https://www.redhat.com/en/blog/podman-inside-container podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello works for me without a problem. But it makes me assume that it's using fusermount inside the container or that it's possible to use it, which does not work when using the same setup. What's more, it doesn't seem to mount anything: podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable # running commands in container cat /proc/mounts > /home/podman/before podman run -d docker.io/busybox sleep 100 cat /proc/mounts > /home/podman/during diff /home/podman/before /home/podman/during # (no difference) It seems like omitting /dev/fuse also works (tested with native overlay): podman run --user podman --security-opt label=disable -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello ## Bindfs Just adding bindfs to the image FROM quay.io/podman/stable RUN dnf -y install bindfs And running a container podman run --user podman --security-opt label=disable --device /dev/fuse -ti built_image_from_above:latest # inside the container cd ~ && mkdir test1 test2 bindfs --no-allow-other test1 test2 fusermount: mount failed: Operation not permitted I'm assuming the behaviour will be the same for other fuse mounts, such as sshfs. Might this be a permission issue within the container or is the host denying it? ---------- # Ideas ## needs privilege This answer implies that to use fuse, you need to be privileged. Setuid is mentioned, but I'm not sure how it's meant. Within the continer: ls -l $(which fusermount3) -rwsr-xr-x. 1 root root 40800 Jul 17 00:00 /usr/bin/fusermount3 ## rootless overlay I've also tried removing the line mount_program from storage.conf and running podman system reset, as describe here . But I'm not sure if this is only about overlay or also fuse. If I don't add /dev/fuse, the device isn't present in the continer: > One other disadvantage of fuse-overlayfs is it requires access to > /dev/fuse. When people try to run Podman and Buildah within a confined > container, we take away the CAP_SYS_ADMIN privileges, even when > running as root. This forces us to use a user namespace so that we can > mount volumes. In order to make this work, users have to add /dev/fuse > to the container. Once we have native overlay for rootless mode (no > CAP_SYS_ADMIN), /dev/fuse will no longer be required. ---------- # Versions Host: Fedora 41 Podman: 5.3.1