Yes, I have tested in RC because the idmap parameter wasn’t accessible (in the ui). I think it was one of the cause of the ui crash because it mess with userns_idmap
You can request it in the Features section of the forum here.
Yeah, it’s available now. It works pretty well. I’m happy with that addition.
Thank you BTW. I’m pretty efficient at systems, but I’m still learning to muddle my way around TN’s API’s and middleware.
Maybe i’m just dumb, but how the hell are you supposed to get nvidia drivers to work with an incus container when you’ve created it with the truenas gui and not from shell? Do we have to use the Environment field to add these:
nvidia.driver.capabilities
nvidia.require.cuda
nvidia.require.driver
nvidia.runtime
You can’t currently. It still needs to be built in to Instances. You can modify the docker-init-nvidia.yaml in the OP to do whatever you need and it will work with Nvidia.
Those are config options, see that config in the OP.
well if the option to passthrough a gpu already exists, why wasn’t the option to get the drivers into the container exposed? this really puts me off from migrating from jailmaker to incus.
I would add it as a feature request:
Expose Incus Config Options in TrueNAS UI
Otherwise for now, just spin up a machine based on that config. I can help you tweak it with only the Nvidia stuff if you don’t need Docker. Let me know.
Done
1 Like
Voted for.
1 Like
In 25.04.1 we have added a fake user account in API responses to allow assigning permissions to the root account in unprivileged containers (creatively named “truenas_container_unpriv_root”). This means if you mount a dataset in a container, and you need the root account in the container to be able to do root things to it, (if it has NFSv4 ACL type) you can add an explicitly entry for that username and give it FULL_CONTROL. This will allow the container root to do things like read, write, chown, chmod, etc.
3 Likes
Hello,
My goal isn’t to argue, but to understand why there are different directives for seemingly similar things.
For Docker, there are Truenas Portainer and Dockge applications in the catalog, which are graphical interfaces for managing Docker other than the Truenas UI.
For Incus, there is a native graphical interface, but ix strongly recommends not using it, otherwise it won’t respond to bug reports.
Could someone explain to me why there are two opposing directives between Docker and Incus?
Ah i wondered why that appeared. I am new to incus, and previously paid no attention to ACLs in linux.
What i really wanted to do was create a dataset for a container and then say ‘just this container’ has access and truenas admin.
I tried creating a new user in truenas (it got uid 3001) and then giving that ownserhsip to the dataset. and then running incus config set my-container raw.idmap "both 0 3001" to map root in the container to user 3001.
unfortunately it looks like the incus orchestration blows this away at container start to the default map, and i can’t set a map with 0 in the UI.
Is there a plan for 25.10 to allow the mapping of root in the LXC to a specfici user? As it stands to seems every container runs as apps on the host?
As such i set the data set to have an owner of apps (568) and add a mask (of RWX) and user/group ACL for my admin user.
No. That pretty much defeats the reason for having the idmapping in the first place. We have plans to allow creation of privileged containers.
I am not sure i understand, or maybe i didn’t articulate the request correctly (new to this specific topic)
I don’t want every container to have the same privilges across a data set.
Containers also shouldn’t be uinversally priviliged they should be unprivilged unless i raise the prvilege explicitly.
I get all containers running as one user (apps) in an inital release. If thats the long term strategy that seems to basically ignore the whole point of many of incus’s features (as i see it from the incus documents).
I am not asking for the container to run as root on the HOST. I am asking to let me map root in the container to a specific low prviliged user on the host, i would like one of these users per container to have very deterministic control of what eac user in each container can and can’t access on the host dataset. This then mean i can reduce prvilieges.
tl;dr i want to take advantage of these features [Idmaps for user namespace - Incus documentation Idmaps for user namespace - Incus documentation to have each container have its own idmap to a discrete account on the host, and to be able to map say user 0 in a container to user 3001 on the host.
All incus containers run unprivileged by default unless specified.
security.privileged: "true"
Currently, it’s the mapped idmaps for all instances. I’d flag a feature request to allow for setting it per instance.
thank you, thats good to know, should i log the feature here on the forum or in Jira?
In the Feature Requests section of the forum. You can also submit a Jira ticket as well.