Hi all,
Incus (and lxc/d noob) here.
I am learning how to use Incus on a Debian bookworm system which has a zfs pool called tank.
I have a user called stephen on the host with uid 1000 and gid 1000 and that user is listed in /etc/subuid and /etc/subgid
I have an unprivileged container called debian3 (also 12) to which I have added a disk device which mounts a dataset from the host, for example:
‘incus config device add debian3 data disk source=/tank/test path=/mnt/test’
/tank/test was created using ‘zfs create tank/test’
Inside tank/test I created another dataset called from_zfs_create, i.e. /tank/test/from_zfs_create
I also created a directory called from_mkdir, i.e. /tank/test/from_mkdir
On the host I issued ‘chown -R stephen:stephen /tank/test’. When I issue ‘ls -la /tank/test’, it shows both from_zfs_create and from_mkdir as owned by stephen stephen
I then issued 'incus config set debian3 raw-idmap ‘both 1000 1000’ and restarted incus and debian3
Once inside debian3 with 'incus exec debian3 --‘bash’, I issue ‘chown -R stephen:stephen /mnt/test’
Now the problem: /mnt/test/from_mkdir is owned by stephen stephen, but /mnt/test/from_zfs_create, is owned by nobody nobody
From what I can gather, for some reason the ownership isn’t being recursively applied to the dataset within the dataset.
I issued ‘incus config device add debian3 data1 disk source=/tank/test/from_zfs_create path=/mnt/test/from_zfs_create’ and then I could set permissions on the directory.
Is this expected behaviour, or should I be able to do this in a more logical and manageable way?
i.e. what is the correct way to bind mount nested zfs datasets in a container?
Mant thanks,
Stephen
Hello Stephen,
Those Volumes/Subvolumes, even if seen as “directory” from human perspective, are more like a file system by themselves, than an actual directory.
Added the ability to tune who’s got which rights, at file system level.
So, there may be slight differences between rights, should they be applied at system level, or at storage backend level 
Tho, subvolume/sub-dataset are independant from their parent, changing rights on a parent dataset doesn’t auto apply to subvolumes.
I went through this doc a few years back, it helped me to beter understand the whole logic behind ZFS ZFS Doc @ Oracle
Hope it helps,
/joen
Hi Joen,
Thanks for the reply.
Essentially then, I would need to add each host dataset to its own mount point, mirroring the directory structure on the guest and deal with chown on an individual basis.
Were I to add all the datasets first and then chown the tree on the guest, would that cascade back up in the host?
I’ll play around and see what happens
I guess I can also create a preseed for adding them if I have a tree with many branches? I haven’t investigated preseed yet.
(I just realised this is what profiles are for; preseed is for incus itself)
Thanks again,
Stephen
PLEASE NOTE before reading, I figured out the answer to my question at the bottom. I was creating the test-file as root in the test instance, doh!
I thought I’d leave this here as it may be useful.
I’m still struggling with this; I wish the documentation had a real world example.
If we take a new scenario:
On the host, I have a ZFS dataset called tank/netdisk.
It is mounted at /mnt/netdisk on the host, and was created by root, so belongs to root:root
In a guest instance, test, it was added to the config as a disk device with path=/mnt/netdisk
By default it is owned by nobody:nobody and I cannot chown -R root:root /mnt/netdisk in the test instance.
I have a user stephen on the host with uid and gid 1000
I create a user stephen in the guest. This user also has uid and gid 1000
If I chown -R stephen:stephen /mnt/netdisk on the host, add a raw.idmap 'both 1000 1000' to the test instance and restart incus and test, I can now chown -R stephen:stephen /mnt/netdisk in the instance test
I then issued touch /mnt/netdisk/test-file on the test instance
If I then ls -la /mnt/netdisk on the host, I see that /mnt/netdisk/test-file belongs to 1000000 1000000
(‘/mnt/netdisk’ belongs to stephen:stephen)
The result of cat /etc/sub[gu]id on the host shows:
root:1000000:1000000000
incus:1000000:1000000000
root:1000:1
stephen:1000:1000
root:1000000:1000000000
incus:1000000:1000000000
root:1000:1
stephen:1000:1000
The result of cat /etc/sub[gu]id on the test instance shows:
stephen:1000000:65535
stephen:1000000:65535
What is happening here to the ownership of test-file?