podman: Unable to expose rclone mount to host when using rootless
/kind bug
Description
Can’t mount/expose mount when using rootless. Also, can’t access the port.
Steps to reproduce the issue:
-
podman pull rclone/rclone:latest -
mkdir -p ~/data/mount
podman run --rm \
--privileged \
--volume ~/rclone:/config/rclone \
--volume ~/data/mount:/data:shared \
--user 1000:1000 \
--volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro \
--device /dev/fuse \
--security-opt apparmor=unconfined \
-p 5590:5590 \
rclone/rclone \
mount remote-crypt:/media /data \
--allow-other \
--rc --rc-addr localhost:5590 --rc-no-auth
Describe the results you received:
The rclone command seems to be working, but the mount isn’t exposed to the host, apparently.
2021/05/04 14:02:10 NOTICE: Serving remote control on http://localhost:5590/
If you ls ~/data/mount, it’ll be empty.
However, it works if you run the podman command with sudo.
Describe the results you expected:
Show the mount in ~/data/mount.
Additional information you deem important (e.g. issue happens only occasionally):
It works if you run the podman command with sudo.
Output of podman version:
Version: 3.0.1
API Version: 3.0.0
Go Version: go1.15.8
Built: Fri Feb 19 13:56:17 2021
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.19.4
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.26-1.fc33.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.26, commit: 777074ecdb5e883b9bec233f3630c5e7fa37d521'
cpus: 4
distribution:
distribution: fedora
version: "33"
eventLogger: journald
hostname: localhost.localdomain
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 5.11.12-200.fc33.x86_64
linkmode: dynamic
memFree: 5937692672
memTotal: 8203341824
ociRuntime:
name: crun
package: crun-0.19-1.fc33.x86_64
path: /usr/bin/crun
version: |-
crun version 0.19
commit: e67a75672412975916dac6b87f8346f870e4b99a
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
path: /run/user/1000/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: true
seccompEnabled: true
selinuxEnabled: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.9-1.fc33.x86_64
version: |-
slirp4netns version 1.1.9
commit: 4e37ea557562e0d7a64dc636eff156f64927335e
libslirp: 4.3.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.0
swapFree: 3944370176
swapTotal: 4100976640
uptime: 43h 40m 50s (Approximately 1.79 days)
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- registry.centos.org
- docker.io
store:
configFile: /home/server/.config/containers/storage.conf
containerStore:
number: 10
paused: 0
running: 0
stopped: 10
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.5.0-1.fc33.x86_64
Version: |-
fusermount3 version: 3.9.3
fuse-overlayfs: version 1.5
FUSE library version 3.9.3
using FUSE kernel interface version 7.31
graphRoot: /home/server/.local/share/containers/storage
graphStatus:
Backing Filesystem: btrfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 12
runRoot: /run/user/1000/containers
volumePath: /home/server/.local/share/containers/storage/volumes
version:
APIVersion: 3.0.0
Built: 1613753777
BuiltTime: Fri Feb 19 13:56:17 2021
GitCommit: ""
GoVersion: go1.15.8
OsArch: linux/amd64
Version: 3.0.1
Package info (e.g. output of rpm -q podman or apt list podman):
podman-3.0.1-1.fc33.x86_64
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
No
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (9 by maintainers)
they are still accessible from the
podman unshareenvironment.if you go into the
podman unshareenvironment, the current user has full capabilities and can see the mounts propagated by containers.Unfortunately this cannot propagate mounts to the host, you need to run as root for that.