Dear all,
I’m deploying a non-root container to renew my router letsencrypt certificate, I have two volumes attached, in one of the two I need to write file as the container user (non-root) but the volume is always mounted as root.
Anyone as expirence on this?
Thanks a lot
Schwitzd
I run service (Unbound DNS) which process is chrooted to mounted directory and is running as non-root user in container, no issue with file writes by service process into that dir and created files are owned by user which is running process.
/ # mount
...
/dev/sda on /etc/unbound type ext4 (rw,nosuid,nodev,noexec,relatime)
...
Mounted directories in containers are not owned by specific uid/gid.
In my case the owner of the mounted directory is root and the permissions for the other users are “r-x” 
Did you try to write file with non-root user into that mounted dir anyway?
yes.. permission denied
Can you paste output of mount command executed from container shell?
Btw, which on ROS version is running? Up to some recent ROS version mounted directories which wasn’t Container store type (without .type file in directory) where read-only in container.
(I suggest reading the whole article. This is only one area where thinking of container.npk as “Docker” will lead you into grief.)
I need to write file as the container user (non-root) but the volume is always mounted as root.
Give my article’s “exfat” workaround a try.
I was wondering regarding term “non-root container” since it is not possible to have Rootless container in ROS and assumed it is related to non-root user process write to mounted dir, but that is not Rootless container, just executed process by non-root user inside container.
This is one of the many reasons I continue to castigate container.npk for being thinly-documented. The mechanism it uses for UID mapping is important to understand in cases like this, but the word “user” scarcely appears in the single-page document for this feature.
Until that situation changes, you have two good options and a bad one:
In case it isn’t clear which of the options I consider the bad one, all of my public container images instantiate and run just fine on RouterOS because they’re built in accord with the microservice model.
Personally I’m not experiencing multi user issues for writes in mounted dirs (from usb on ext4) in containers. But in OP is not stated which on ROS version is running, from which fs is mounted (internal, external, which fs type), is Contanier store mount type or not…
Yes, more details are needed here.
Hi guys!
@tangent many thanks for sharing the link I will read it as soon as possible.
To give you more details:
Mount:
/dev/sda on / type ext4 (rw,nodev,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=65536k,mode=755,uid=32768,gid=32768)
/dev/sda on /ssh type ext4 (rw,nosuid,nodev,noexec,relatime)
/dev/sda on /letsencrypt type ext4 (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,uid=32768,gid=32768)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,uid=32768,gid=32768)
what you mean “is Contanier store mount type or not…”?
Currently I workaround the issue by forking routeros-letsencrypt-docker repository and adding in the dockerfile
chown -R lego:lego /letsencrypt
, in this way everything is working
Cheers
Contanier store is ROS files list item type used for directories where its content is skipped for reading recursively in /file (or Files in Winbox/Webfig). ROS marks directories as such when in directory .type file is present with content
container
, this is used to not overpopulate files list since ROS reads all items as flat list from fs recursively and when there are a lot of items in dir it would take long time to all read files, like for eg. when mounting external disk in ROS with thousands of files and dirs on it.
Containers have system root dir stored in some configured dir on host system, by default ROS creates .type in it to avoid reading its contents for above mentioned reason, it does the same for mounts when created if src mount directory doesn’t already exists on host.
In some cases for mounts it is convenient to have dir items listed in ROS to have possibility to backup or update certain files for container like some configuration, ssl certs. etc… In such case mount src needs to point to already existing dir (where .type file not exists in it) before container is ever started or to delete .type file in dst dir from container shell when container is started and mount dir items will be listed in ROS and it will be rw from ROS.
As I examined my mounts for containers, all dst’s points to already existing dirs in container image which have already appropriate rights for users. It seems that in ROS container such rights are inherited from fs since there are no options in ROS to specify uid/gid and umask for mounts.
Your workaround as I see it is correct solution to resolve this.
Hi optio,
Thx for the amazing explanation 