rhatdan
commented
3 weeks ago @giuseppe PTAL
Open HolgerHees opened 1 month ago
rhatdan
commented
3 weeks ago @giuseppe PTAL
giuseppe
commented
3 weeks ago Is your container creating a lot of files on its overlay upper directory? Otherwise recreating the container is not much more expensive than restarting it.
Once resolved, the original symlink does not affect what the container sees. You could try --mount type=bind with the no-dereference option help so can bind mount the symlink itself but in that case, you'd need to bind mount /dev since the symlink is then resolved inside the container.
HolgerHees
commented
3 weeks ago @giuseppe I already "fixed" it by mounting the /dev inside the container. No additional mount or mount type was needed. But this is a security hole in my opinion, because it gives also access to other devices.
the container itself is creating a lot of files, because it is initializing several minutes and is downloading a lot of additional "plugins" based on configs. (https://hub.docker.com/r/openhab/openhab)
the reason why I create this bug ticket is that docker was able to handle this and I guess, your goal is to be as compatible as much as possible.
I ported all of my 31 different containers from docker to podman and this is the only thing which behaves completely differently. The rest had only minor differences where I was able to find a proper replacement.
With podman inspect the related part looks like
"Devices": [
{
"PathOnHost": "/dev/ttyUSB0",
"PathInContainer": "/dev/ttyMyTestDevice",
"CgroupPermissions": ""
}
],with docker inspect it looks like
"Mounts": [
{
"Type": "bind",
"Source": "/dev/ttyMyTestDevice",
"Destination": "/dev/ttyMyTestDevice",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],inside the docker container it looks like
/ # ls -al /dev/
total 0
drwxr-xr-x 5 root root 380 Sep 28 15:15 .
drwxr-xr-x 1 root root 134 Sep 28 15:15 ..
crw--w---- 1 root tty 136, 0 Sep 28 15:15 console
lrwxrwxrwx 1 root root 11 Sep 28 15:15 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Sep 28 15:15 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Sep 28 15:15 full
drwxrwxrwt 2 root root 40 Sep 28 15:15 mqueue
crw-rw-rw- 1 root root 1, 3 Sep 28 15:15 null
lrwxrwxrwx 1 root root 8 Sep 28 15:15 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Sep 28 15:15 pts
crw-rw-rw- 1 root root 1, 8 Sep 28 15:15 random
drwxrwxrwt 2 root root 40 Sep 28 15:15 shm
lrwxrwxrwx 1 root root 15 Sep 28 15:15 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Sep 28 15:15 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Sep 28 15:15 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Sep 28 15:15 tty
crw-rw---- 1 root 490 188, 0 Sep 28 15:14 ttyMyTestDevice
crw-rw-rw- 1 root root 1, 9 Sep 28 15:15 urandom
crw-rw-rw- 1 root root 1, 5 Sep 28 15:15 zeroon my host it looks like
lrwxrwxrwx 1 root root 12 28. Sep 17:14 /dev/ttyMyTestDevice -> /dev/ttyUSB0I read somewhere since kernel v5.12+ bind mount supports symlinks with the flag AT_SYMLINK_NOFOLLOW on files.
Issue Description
I recently migrated all my docker containers to podman. There are 34 containers of different types. I was amazed at how easy and straightforward it was.
But one problem remains. I have 2 containers that access devices that are created via a UDev rule. They are USB sticks that create symlinks using a udev rule. These in turn are mounted in the container.
So far it works under podman. The problem under podman is the bind mount, which mounts the inode of the dissolved device.
i.e. after a reboot or when the USB stick is plugged in again, the device is available under a different /dev/USBX. The UDEV rule ensures that it is available under the same symlink. Only the container still points to the old USB device.
This was not a problem under Docker and worked for years.
What is the recommended way to deal with this problem?
Currently, the container has to be recreated, which is absolute overkill. Currently, I only start my 34 containers after a reboot again. Recreating them all on suspicion would slow down the entire startup process extremely and also present me with new problems.
Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
mounted symlink point to the wrong device
Describe the results you expected
mounted symlink should point to the correct device
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
No response
Additional information
No response