chown/chmod on mounted directory: Permission denied

[solarkraft]

Hey, I really like lima so far and wish I could use it for development, but unfortunately I've come across a workflow-breaking issue.

My docker image copies files into a mounted directory and changes their ownership to the custom user 1000. The copying works just fine, but the chown fails with Permission denied.

This issue can be confirmed in a shell; chmod fails in the same way.

root@wiki:/# chown 1000 /app/
root@wiki:/# chown 1000 /usr/
root@wiki:/# chmod 777 /app/
root@wiki:/# chmod 777 /usr/
root@wiki:/# chown 1000 /config/
chown: changing ownership of '/config/': Permission denied
root@wiki:/# chmod 777 /config/
chmod: changing permissions of '/config/': Permission denied

It's the same for a custom mount inside of $HOME and a directory in /tmp/lima.

The files end up with
drwxrwxrwx 1 nobody nobody 128 Sep 9 13:17 php

Manually touched files get
-rw-r--r-- 1 nobody nobody 0 Sep 9 13:22 test

I'm on an M1 Macbook Pro with macOS 12 and installed QEMU using the provided shell file. The same setup just works with Docker Desktop.

[AkihiroSuda]

This is a known limitation of the current sshfs server, which works without the root privilege.

[solarkraft]

Thanks for the info! Is it going to be resolved when VirtFS is built in? Is running rootfully a workaround and is it documented somewhere? Starting a rootful VM works, but sudo lima nerdctl compose up fails with FATA[0000] must not run as the root.

[abiosoft]

I am actually able to modify mounted directories as long as the directory is writeable by the host's macOS user.
I'll give your docker image a try.

Sorry, I didn't see your most recent comment #231 (comment)

[abiosoft]

but sudo lima nerdctl compose up fails with FATA[0000] must not run as the root.

It should actually be lima sudo nerdctl compose up?

[solarkraft]

Thanks for the hint. Unfortunately doesn't resolve the permission issue.

[diepfote]

This is a known limitation of the current sshfs server, which works without the root privilege.
@AkihiroSuda

How could we resolve this with a quick fix (less security but more interop)? If I disable rootless containerd and enable rootful on the guest I can't use nerdctl:

FATA[0000] rootless containerd not running? (hint: use `containerd-rootless-setuptool.sh install` to start rootless containerd): stat /run/user/501/containerd-rootless: no such file or directory

OR

why are you using allow_root instead of allow_other

lima/pkg/hostagent/mount.go

Line 51 in 8092199

SSHFSAdditionalArgs: []string{"-o", "allow_root"},

?

Thanks for taking the time :)

[AkihiroSuda]

If we could get https://github.com/afbjorklund/qemu/commits/9p-darwin merged into the upstream, we will be able to store the file owner info into xattr (or a separate file). https://wiki.qemu.org/Documentation/9psetup (mapped-xattr, mapped-file)

I'm not sure we will use 9p by default, though, due to a performance issue.

[diepfote]

Thanks.

Still not quite sure why the sshfs option allow_other would not be an option.
From the manpage:

   FUSE options:
       -d -o debug
              enable debug output (implies -f)

       -f     foreground operation

       -s     disable multi-threaded operation

       -o allow_other
              allow access to other users

       -o allow_root
              allow access to root

[diepfote]

or maybe a hacky way of doing it:

       -o uid=N
              set file owner

       -o gid=N
              set file group

[AkihiroSuda]

These flags have nothing to do with allowing chown/chmod.

[diepfote]

ahh this is how I confused you. I found this issue after looking for issues regarding "incorrect" host mount permissions.
My suggestion was merely about fixing permissions for host mounted dirs for non-root users in a container.

Would that solve it?

Sorry for the confusion.