Volume mount fails if symbolic link exists in target folder

[mariovor]

Machine: EC2 machine on AWS OS: Ubuntu 20.04, Kernel: 5.13.0-1017-aws Sysbox: 0.4.1 ShiftFs: No

To reproduce:

Launch the "getting started example":

docker run --runtime=sysbox-runc -it --rm -P --hostname=syscont nestybox/ubuntu-bionic-systemd-docker:latest -> Login

Start inside the container an nginx (I noticed the problem with nginx). docker run -v test_vol:/etc/nginx -d --name test nginx

The container creation fails with docker: Error response from daemon: failed to copy xattrs: failed to list xattrs on /var/lib/docker/overlay2/30876adcd99009c406b53489b42f014aeef39568c3844414c2eb04a18d52e356/merged/etc/nginx/modules: no such file or directory.

The folder /etc/nginx in the container is a symbolic link, see the result of a nginx container running outside of a conatainer:

ls -lh /etc/nginx
total 28K
drwxr-xr-x 2 root root 4.0K Mar 22 15:11 conf.d
-rw-r--r-- 1 root root 1007 Jan 25 15:03 fastcgi_params
-rw-r--r-- 1 root root 5.3K Jan 25 15:03 mime.types
lrwxrwxrwx 1 root root   22 Jan 25 15:13 modules -> /usr/lib/nginx/modules
-rw-r--r-- 1 root root  648 Jan 25 15:13 nginx.conf
-rw-r--r-- 1 root root  636 Jan 25 15:03 scgi_params
-rw-r--r-- 1 root root  664 Jan 25 15:03 uwsgi_params

Let me know how to provide more useful information to you!

Debug info:

root@xxxx:/home/ubuntu# systemctl status sysbox
● sysbox.service - Sysbox container runtime
     Loaded: loaded (/lib/systemd/system/sysbox.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-03-22 15:09:33 UTC; 17min ago
       Docs: https://github.com/nestybox/sysbox
   Main PID: 781 (sh)
      Tasks: 2 (limit: 1120)
     Memory: 648.0K
     CGroup: /system.slice/sysbox.service
             ├─781 /bin/sh -c /usr/bin/sysbox-runc --version && /usr/bin/sysbox-mgr --version && /usr/bin/sysbox-fs --version && /bin/s>
             └─915 /bin/sleep infinity

Mar 22 15:09:36 ip-172-20-7-135 sh[895]:         version:         0.4.1
Mar 22 15:09:36 ip-172-20-7-135 sh[895]:         commit:         380f1e8f071c4ace39fd9d5b7217db58fe8eb8a8
Mar 22 15:09:36 ip-172-20-7-135 sh[895]:         built at:         Fri Oct  1 19:42:27 UTC 2021
Mar 22 15:09:36 ip-172-20-7-135 sh[895]:         built by:         Rodny Molina
Mar 22 15:09:36 ip-172-20-7-135 sh[901]: sysbox-fs
Mar 22 15:09:36 ip-172-20-7-135 sh[901]:         edition:         Community Edition (CE)
Mar 22 15:09:36 ip-172-20-7-135 sh[901]:         version:         0.4.1
Mar 22 15:09:36 ip-172-20-7-135 sh[901]:         commit:         670e9746ceee06714681e34463a2d9f7c197bcd4
Mar 22 15:09:36 ip-172-20-7-135 sh[901]:         built at:         Fri Oct  1 19:42:06 UTC 2021
Mar 22 15:09:36 ip-172-20-7-135 sh[901]:         built by:         Rodny Molina

root@xxxx:/home/ubuntu# cat /etc/docker/daemon.json 
{
    "userns-remap": "sysbox",
    "runtimes": {
        "sysbox-runc": {
            "path": "/usr/bin/sysbox-runc"
        }
    },
    "bip": "172.21.0.1/16",
    "default-address-pools": [
        {
            "base": "172.25.0.0/16",
            "size": 24
        }
    ]
}

[ctalledo]

Hi @mariovor,

Thanks for trying Sysbox and for filing this issue.

The problem you found is fixed in the upstream code and will be in the upcoming v0.5.0 release (this week). It was a bug in the way Sysbox dealt with the listxattr() syscalls inside the container (particularly when that syscall was given a path with a symbolic link).

If you want to get the fix right away, you can try building Sysbox from source, though I suggest you wait since the v0.5.0 release is imminent.

[ctalledo]

Closing since fix is committed upstream; will be present in the v0.5.0. release.

[mariovor]

Happy to confirm that v0.5.0. fixed the issue for me.