Is it possible to mount disk/source from host to container with specific UID without shiftfs?

1

Is it possible to mount disk/source from host to container with specific UID without shiftfs?
I want all files from mounted disk to have specific UID
With unprivileged container and without shiftfs all files/dirs are unaccessible with nobody/nogroup even for root in container

2

Try setting up raw.idmap. It works exactly the same in Incus and LXD, simply substitute incus for lxc. Value 1000 corresponds to the UID and GID of the default user in the container (check those using id -u and id -g commands). The $(id -u) and $(id -g) will get your host user UID and GID.

printf "uid $(id -u) 1000\ngid $(id -g) 1000" | incus config set <container_name> raw.idmap -

This should look like this in your config:

$ incus config show <container_name>

...
raw.idmap: |-
  uid <host_user_uid> <container_user_uid>
  gid <host_user_gid> <container_user_gid>
...
3

Ok now host source is mounted with host_user_uid
but I am still cannot access files with error
Permission denied

4

Ok I see
I can access with su from host container
Container start is very slooooow
Is it because every file of container user must be remapped?
Is it make container slower?
How can I revert this in future?

5

It shouldn’t make containers visibly slower. What is the user’s UID and GID on the host and in container?

6

I setup raw.idmap
uid 112 112
gid 120 120

7

These are weird values. What OS do you use?

8

Ubuntu 20.40

9

When you run id -u and id -g commands on your host, you get 112 and 120 values instead of 1000?

10

Maybe adding a bit of logic to it : what you basically want, is to map UID/GID of your container user, to match your “host administrative user”, so it can seemlessly access files on the host, am i right ?

As explained by qkiel, you then needs to tell your container, to run, with same IDs, using raw.idmap.

The goal here is to specify, the UID/GID of the user logged on your host.
Recently came by a post explaining that, idmap only works for root acount, maybe is it the cause of the behaviour your describe ? :slight_smile:

Hope it helps,

/joen

11

Thx, raw.idmap works as expected but I wonder
1.Is it safe to share host directory - disk source - to multiple containers? no conflicts?
shared dir is mounted as ext4 on containers
2.Is it normal that raw.idmap works different in containers for host users with uid > 1000
I came with some conclusion

raw.idmap: |-
    uid 112 112
    gid 120 120
    uid 1004 1004
    gid 1004 1004

I cant access - as root in container - files for user with uid 112 without sudo
I can access - as root in container - files for user with uid 1004

12
  1. It’s safe to share host directory with many containers
  2. I’m not sure you’re using the right values

For example, I use Ubuntu 22.04 as the host. When I run id -u and id -g commands, I get UID 1000 and GID 1000:

$ id -u
1000
$ id -g
1000

Now let’s start an Ubuntu 22.04 container and log in:

incus launch images:ubuntu/22.04/cloud test-container
incus exec test-container -- sudo --login --user ubuntu

When I run the same id -u and id -g commands inside container, I get UID 1000 and GID 1002:

$ id -u
1000
$ id -g
1002

This means my raw.idmap should look like this:

raw.idmap: |-
  uid 1000 1000
  gid 1000 1002

I can set it with this command:

printf "uid 1000 1000\ngid 1000 1002" | incus config set test-container raw.idmap -
13

I want to map 2 users with uid/gid 112/120 and 1004/1004

14

Ok. Do you have users in container with uid/gid 112/120 and 1004/1004?

The reason I’m asking is that the default user ubuntu in Ubuntu 22.04 container have uid/gid 1000/1000 (if you use LXD container) or 1000/1002 (if you use Incus container). So for LXD you want to map it like this:

raw.idmap: |-
  uid 1004 1000
  gid 1004 1000
15

Sure users are created by me in host and containers

16

Maybe is it the actual “problem” : it seem that IDmapping works on UID / GID > 1000

This would explain, why, for user 1004:1004 it is actually working, while for user 112/120 you still have to sudo in order to access the files :slight_smile:

Are those UID/GID mendatory ? Defaults id, are distribution specific… 112 reminds me of RPC, not sure tho :slight_smile: It is common use, to bind ID above 1000, as lower id, can conflict with some packaged programs that adds a system user with specific IDs :slight_smile:

Except if you try to run something that actually needs to be allocated an id < 1000, i never had to do so, but there are so many use cases… :slight_smile:

Hope it helps,

/joen