TrueNAS 26.0.0-BETA.2 is Now Available!

Thanks for the diagnosis. If this is not in the docs, we should view it as a bug. Can you report it so we can track.

1 Like

can anyone check which version of nut truenas 26 uses?

This is from my VM 26.0.0-BETA.2

Welcome to TrueNAS
truenas_admin@truenas[~]$ nut-scanner --version
Cannot load XML library (libneon.so.27) : file not found. XML search disabled.
Cannot load AVAHI library (libavahi-client.so.3) : file not found. AVAHI search disabled.
Network UPS Tools - 2.8.1
truenas_admin@truenas[~]$ 

https://ixsystems.atlassian.net/browse/NAS-141668

And the link over to Failed to configure docker for Applications: Unable to determine default interface - #32 by Momi_V

These are the same, I initially didn’t find the other thread.

1 Like

I have noticed that the current api endpoints for LXC creation are a bit thin right now (going by the docs). Is this going to be expanded upon for those of us that prefer to do the Infrastructure as Code thing?

Correct, very disappointed as well.

When you have to add features during the ā€œbetaā€ process, you are already behind!

Proper beta code never adds new features, commands!!!

Let’s see what the release brings…

Everything in the UI is available via APIs… so its best to be specific about what you need it to do.

We do see LXC as a less dynamic infrastructure in comparison with docker containers. What is it you are trying to do?

If that is the case the I suppose it is less of a capability issue than a documentation one: I have not been able to figure out how to do custom uid/gid mapping via the api, it also does not help that there are no concrete examples shown on how one creates a LXC plus all the details involved in setting it up (storage mapping, networking, etc). I am trying to write up most of the logic in advance of actually moving to scale (I plan to do so with the 26 release) in order to minimize the downtime of the services I am currently running in jails. Most things will be going to docker containers which were clearer in how one did all of these things. The two that will need to be LXCs though are proving much more difficult to figure out how everything interacts from just the api docs alone.

The UI only consumes documented public API endpoints provided by the backend server. Anything the webui does, you can do in your API client.

^^^ userns_idmap

^^^ userns_idmap

The specific idmap settings used by the UI are in the user / group settings.

^^^ beginning of container APIs

^^^ our tests dirs (contain lots of examples of using container APIs, idmapping, etc).

Not disputing that at this point. And it does seem like your internal documentation is very good, however that is not where I am coming from. Realistically I am going to have somewhere between 1 - 3 hours to work on this project each weekend (maybe a few additional stolen minutes here or there, I am very busy) and that there is not (that I can easily find anyway) examples that show how one would go through and setup a notional lxc container using the midclt command with all the calls laid out with explanations of what each does (and why you do it in that order). This makes the exercise considerably more difficult as someone who is not familiar with your codebase nor likely to go digging through your tests (or find them understandable).

We could in theory put something in the api_client repo’s examples dir, but it’d have to wait until 26.0 release since there is still risk of API churn. Simple fact of the matter that if something absolutely critical comes out during beta process the APIs may change. The contract is not settled until release.

Another way of looking at this is: this is your moment to have some influence on the direction APIs work out. If you find something cumbersome or broken, file tickets in our jira.

Generally trying to script midclt commands with this is not a great way to interact with API programmatically because you’re setting up / tearing down sessions with each operation (which may get you rate-limited). You should look at our API client repo and use the python client appropriately for automation tasks. GitHub - truenas/api_client Ā· GitHub

I can’t believe I’m saying this, but you sorta rhyme with announcements of the MCP Server?

The idea of the forums is create a place where we can all collaborate.

Maybe start a General thread with the problem and people can contribute.
The TrueNAS 26 is still in beta, so docs and examples will improve as we get closer to Release.

After upgrading from TrueNAS 25.10.3 I met the exact same issue
Not sure if you managed to find a better fix than me, but the problems comes from the newly introduced ID Map Type which was set for all containers as Default (which blocks access to update cgroups) and it can only be changed when you create the container.
The only fix I found in my case where I had only one container in use was to create a new one that had ID Map Type as Privileged, copy the /var/lib/docker/volumes folder to the new container and use that one.
If someone found an easier solution please let me know c: This is the what I did based on what I found, so there’s a huge chance I missed something.

You may need to also set Capabilities Policy to Allow to run docker in a nested container. See https://www.truenas.com/docs/scale/26/containers/managingcontainers/#running-nested-containers.

1 Like

You are 100% correct, I forgot to mention that one :sweat_smile: Thank uu so much

1 Like

Any idea when Beta 3 might come out?

You get the road map here.

1 Like

Not long to wait I see. Thanks Hervon

The future is now:

2 Likes