Dear Podman users and developers I wonder if you have encountered a similar problem to mine and whether you may have a solution. Description of the problem: I cannot run containers where non-root users of the container (e.g. uid 101 of nginx for a nginx container) have possibility to write to a mounted folder from virtualbox. Even when mounting the shared folder with full writing permissions (dmode/fmode 0777), the new files created appear as belonging to nobody (uid 65534). This prevents any application which creates new files or directories (e.g. wordpress). The setup: * I have a linux virtual machine (Alpine 3.11.6, tested on both 5.4.27 and 5.4.34 kernels) running over a linux host (Ubuntu 18.04.4 LTS) on which I create and run rootless pods and containers. * virtualbox version: 5.2.34 * podman version: tried both 1.8.2 and 1.9.1 * shared folder and its contents are owned by 1001:1001 on the host * the folder is mounted in the vm with the command /sbin/mount.vboxsf -o rw,uid=100100,gid=1001,dmode=0775,fmode=0664 wpcontent /media/sf_wpcontent * the user running the container in the vm has id/gid 1001:1001 and subuid 100000:65536 Investigation: I'll paste the result of commands run at three levels: the host, the vm and the container. * This is on the underlying host: $ ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 2 1001 1001 20480 Jan 31 16:05 01 drwxrwxr-x 2 1001 1001 12288 Feb 18 08:34 02 drwxrwxr-x 2 1001 1001 4096 Apr 21 16:48 04 $ touch uploads/sites/3/2020/host-touched $ ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 2 1001 1001 20480 Jan 31 16:05 01 drwxrwxr-x 2 1001 1001 12288 Feb 18 08:34 02 drwxrwxr-x 2 1001 1001 4096 Apr 21 16:48 04 -rw-rw-r-- 1 1001 1001 0 Apr 22 15:10 host-touched $ sudo chown 100100:100100 uploads/sites/3/2020/host-touched $ ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 2 1001 1001 20480 Jan 31 16:05 01 drwxrwxr-x 2 1001 1001 12288 Feb 18 08:34 02 drwxrwxr-x 2 1001 1001 4096 Apr 21 16:48 04 -rw-rw-r-- 1 100100 100100 0 Apr 22 15:10 host-touched * This is in the VM: $ ls -ln /media/sf_wpcontent/uploads/sites/3/2020 total 36 drwxrwxr-x 1 100100 1001 20480 Jan 31 16:05 01 drwxrwxr-x 1 100100 1001 12288 Feb 18 08:34 02 drwxrwxr-x 1 100100 1001 4096 Apr 21 16:48 04 -r-xr-xr-x 1 100100 1001 0 Apr 22 15:10 host-touched $ touch /media/sf_wpcontent/uploads/sites/3/2020/vm-touched $ ls -ln /media/sf_wpcontent/uploads/sites/3/2020 total 36 drwxrwxr-x 1 100100 1001 20480 Jan 31 16:05 01 drwxrwxr-x 1 100100 1001 12288 Feb 18 08:34 02 drwxrwxr-x 1 100100 1001 4096 Apr 21 16:48 04 -r-xr-xr-x 1 100100 1001 0 Apr 22 15:10 host-touched -r-xr-xr-x 1 100100 1001 0 Apr 22 15:28 vm-touched $ chown 100100:100100 /media/sf_wpcontent/uploads/sites/3/2020/vm-touched $ ls -ln /media/sf_wpcontent/uploads/sites/3/2020 total 36 drwxrwxr-x 1 100100 1001 20480 Jan 31 16:05 01 drwxrwxr-x 1 100100 1001 12288 Feb 18 08:34 02 drwxrwxr-x 1 100100 1001 4096 Apr 21 16:48 04 -r-xr-xr-x 1 100100 1001 0 Apr 22 15:10 host-touched -r-xr-xr-x 1 100100 1001 0 Apr 22 15:28 vm-touched This is in the container: # ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 1 101 0 20480 Jan 31 16:05 01 drwxrwxr-x 1 101 0 12288 Feb 18 08:34 02 drwxrwxr-x 1 101 0 4096 Apr 21 16:48 04 -r-xr-xr-x 1 65534 1001 0 Apr 22 15:10 host-touched -r-xr-xr-x 1 65534 1001 0 Apr 22 15:28 vm-touched # touch uploads/sites/3/2020/cont-touched $ ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 1 101 0 20480 Jan 31 16:05 01 drwxrwxr-x 1 101 0 12288 Feb 18 08:34 02 drwxrwxr-x 1 101 0 4096 Apr 21 16:48 04 -r-xr-xr-x 1 65534 1001 0 Apr 22 15:31 cont-touched -r-xr-xr-x 1 65534 1001 0 Apr 22 15:10 host-touched -r-xr-xr-x 1 65534 1001 0 Apr 22 15:28 vm-touched # chown 100100:100100 uploads/sites/3/2020/cont- touched chown: uploads/sites/3/2020/cont-touched: Invalid argument # chown nginx:nginx uploads/sites/3/2020/cont-to uched # ls -ln uploads/sites/3/2020 total 36 drwxrwxr-x 1 101 0 20480 Jan 31 16:05 01 drwxrwxr-x 1 101 0 12288 Feb 18 08:34 02 drwxrwxr-x 1 101 0 4096 Apr 21 16:48 04 -r-xr-xr-x 1 65534 1001 0 Apr 22 15:31 cont-touched -r-xr-xr-x 1 65534 1001 0 Apr 22 15:10 host-touched -r-xr-xr-x 1 65534 1001 0 Apr 22 15:28 vm-touched rm -f uploads/sites/3/2020/cont-touched rm: can't remove 'uploads/sites/3/2020/cont-touched': Value too large for data type The behaviour is inconsistent, for example: in the vm: $ ls -ln uploads/sites/ total 16 drwxrwxr-x 1 100100 1001 4096 Apr 22 15:52 2 drwxrwxr-x 1 100100 1001 4096 Apr 22 08:52 3 drwxrwxr-x 1 100100 1001 4096 Jan 21 14:30 4 drwxrwxr-x 1 100100 1001 4096 Jun 14 2017 5 inside the container: # ls -ln uploads/sites/ total 16 drwxrwxr-x 1 65534 1001 4096 Apr 22 15:52 2 drwxrwxr-x 1 101 0 4096 Apr 22 08:52 3 drwxrwxr-x 1 65534 1001 4096 Jan 21 14:30 4 drwxrwxr-x 1 65534 1001 4096 Jun 14 2017 5 To clear the inconsistencies I can use the command (as vm's root): # echo 3 > /proc/sys/vm/drop_caches This appears to "correct" the problem by realigning the id of the directories. But everytime a new file or directory is created, they are still created as user nobody (65534). Even for applications where no new files/directories are created (e.g. appending to existing file), the drop_caches command would need to be applied everytime the machine is rebooted, thus rendering the whole system not really stable/usable. The only two "solutions" that "work" are: 1) to have containers where the services run as root. Thus not using subuid and files are created as the user running podman. Mounting the shared folder with uid equal to the podman user is ok. Obviously this is not always possible/desirable, as containers often have a different user running the command. 2) mounting the shared folder with full permissions and without using a subuid, i.e. like this: /sbin/mount.vboxsf -o rw,uid=1001,gid=101,dmode=0777,fmode=0555 wpcontent /media/sf_wpcontent this is obviously far from desirable, as it allows any user of the vm permission to write into the folder or delete files If you have used rootless containers writing on shared virtual folders and have found a working solution, please let me know. Thank you very much! Best regards Giuseppe PS: I've also tried adding a user with uid/gid 100100:100100 in the vm. This does not make any difference to the problems reported above PPS: I've also tried changing id/gid of host folder or of the user in the vm running podman. No changes.