Mounting Datasets in LXC (shift=true)

I’m having some issues testing with the new incus LXC functionality. I love that I can mount datasets from the host directly inside the container and it is super fast. The issue I am having is with permissions.

On the host I have a configs dataset created with the apps preset and beneath it I have many other datasets with mixed permissions. Some are made with the apps preset, others were created with generic and use either 770 with root:root ownership or even 777.

When I mount the configs dataset into the container using shift=true only the configs dataset itself is visible with the correct permissions. Every dataset underneath it is visible as root root 770 permissions. It seems almost like the shift=true is not recursive?

Does anyone have any idea what is going on here?

I have also noticed this is not the case with directories. For example I have a media dataset (made with the apps preset) I pass into the container which has 3 subdirectories: movies, media, downloads. All of the subdirectories have correct permissions and are accessible when using shift=true.

According to docs the only user which this should currently work for is apps but I’m not even seeing that with datasets under configs which are the apps user:group.

Can anyone else confirm?

I’m not sure what you’re referring to here. Perhaps you were looking at an old release note from RC.1? If there is something in the actual docs stating this, please link it so I can make sure it gets updated.

As for your main question, instead of using shift=true, you should use ID mapping to set up permissions between the containers and the host. You can do this in the UI though the Map User And Group IDs screen.

yes i apologize about that. i see in the latest release notes there is the UI to map host user to container user.

the issue is i see use apps is already mapped but it appears not to be working. when i map a host dataset which was created with the apps permission preset and i create a user:group apps:apps inside the container, i do not have permissions on subdatasets to access any data. i have no issue reaching the top level dataset, but any subdatasets, no matter who owns them and what their permissions are, are usable inside the container.

So you’ve created an apps (568:568) account in the container, and with this you can access the parent but not child datasets? This may be not an issue with permissions at all but with the mount not being recursive. If you mount both the parent and child datasets in the instance config separately, do you get access from the container then?

edit: or it may be something you did in shell messing up permissions. This is a parent and a child dataset, both created with the apps preset and default ACL for the preset (so root ownership, apps is granted allow and modify). I mounted only the parent dataset to a Debian Bookworm container. No problem accessing either

apps@deb:/root$ ls /mnt/instest
instest2
apps@deb:/root$ ls /mnt/instest/instest2
apps@deb:/root$ touch /mnt/instest/instest2/test.txt
apps@deb:/root$ ls /mnt/instest/instest2
test.txt

so when creating a new LXC from Ubuntu Noble (all default settings) and then using the UI to map datasets into the container i get nothing:

test dataset made with apps preset.
in-test & otherset made with apps preset
generic made with generic preset

root@test:~# groupadd -g 568 apps || true && useradd -u 568 -g apps -m apps || true
useradd warning: apps uid 568 outside of the UID_MIN 1000 and UID_MAX 60000 range.
root@test:~# cd /
root@test:/# mkdir test
root@test:/# ls -l
drwxrwx---   5 nobody nogroup   5 May 12 14:38 test
root@test:/# cd test/
bash: cd: test/: Operation not permitted

now i will mount the same test dataset in the cli with shift=true:

root@truenas-test[/home/truenas_admin]# incus config device add test testdisk disk source=/mnt/tank/test path=/test shift=tr
ue
Device testdisk added to test

and from inside the container:

root@test:~# cd /
root@test:/# ls -l
drwxrwx---   5 root   root      5 May 12 14:38 test
root@test:/# cd test/
root@test:/test# ls -l
total 2
drwxrwx--- 2 root root 2 May 12 14:38 generic
drwxrwx--- 2 root root 2 May 12 14:38 in-test
drwxrwx--- 2 root root 2 May 12 14:38 otherset

root@test:/test# cd in-test/
root@test:/test/in-test# touch test
touch: cannot touch 'test': Operation not permitted

root@test:/test# cd generic/
root@test:/test/generic# touch test
touch: cannot touch 'test': Operation not permitted

any ideas why this worked for you and not me?

After creating apps in the container, I switched user and logged in as apps. You’re still trying to access the datasets as root, which isn’t mapped.

when i do an su apps i do finally have permissions. here’s my question then, since I am root inside the container, should I not have permissions over the dataset since it is owned by root on the host?

If it is a user mapping permission issue, is it possible to map the root user on the host to the root user in the container?

Root is not idmapped because doing so would break the isolation of the container. There will be an option to map a non-privileged truenas_container_unpriv_root account to the container root in 25.04.1: Linux Jails (containers/vms) with Incus - #361 by awalkerix

1 Like