Upgraded to 25.04 from 24.10 and cannot change builtin group membership

In Scale and Core before, it was possible using the shell and using → usermod. That’s why certain users are member of certain groups right now.

But today this feature has gone.

root@truenas[/home/admin]# usermod -aG group user
[sss_cache] [confdb_init] (0x0010): Unable to open config database [/var/run/sssd-cache/db/config.ldb]
Could not open available domains
[sss_cache] [confdb_init] (0x0010): Unable to open config database [/var/run/sssd-cache/db/config.ldb]
Could not open available domains
root@truenas[/home/admin]#

Unfortunately it doesn’t work over the GUI. So, when you go to

  • Credentials
  • Groups
  • Update Members
    e.g.
    Manage members of docker group

you get

Validation Error

[EINVAL] group_update.users: Group membership for this builtin group may not be changed.

and with → more Info

Error: Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/middlewared/api/base/server/ws_handler/rpc.py”, line 323, in process_method_call
result = await method.call(app, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/api/base/server/method.py”, line 40, in call
result = await self.middleware.call_with_audit(self.name, self.serviceobj, methodobj, params, app)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 883, in call_with_audit
result = await self._call(method, serviceobj, methodobj, params, app=app,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 692, in _call
return await methodobj(*prepared_call.args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/service/crud_service.py”, line 266, in update
return await self.middleware._call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 692, in _call
return await methodobj(*prepared_call.args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/service/crud_service.py”, line 287, in nf
rv = await func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/api/base/decorator.py”, line 88, in wrapped
result = await func(*args)
^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/plugins/account.py”, line 1869, in do_update
verrors.check()
File “/usr/lib/python3/dist-packages/middlewared/service_exception.py”, line 72, in check
raise self
middlewared.service_exception.ValidationErrors: [EINVAL] group_update.users: Group membership for this builtin group may not be changed.

So there is no way to add a user to a builtin group anymore, isn’t it?

Example:
for ampache and the docker container volumes the (main) user must be a member of www-data.

At the moment I can’t add any users to the group ‘www-data’ anymore, just because www-data is a builtin group!!??!!??!!

To be clear. Now it is not possible, to reasign any users to any builtin groups.

Is it a feature, or is it a bug?

With a couple of exceptions builtin group memberships cannot be changed. This was an intentional design decision.

1 Like

With a couple of exceptions builtin group memberships cannot be changed. This was an intentional design decision.

Ugggh… this is unfortunate. I can no longer add users to my “backup” group. Will need to re-do permissions. What a pain.

Yes… I’m “using it wrong”.

That is very inconvenient.

It has worked for 100 years.

1 Like

+1 to this being a terrible idea. Make it a multi click process with more annoying visual verification if you’re worried about inexperienced users making system-breaking changes but you need to still allow your veteran users the ability to do what they need to do.

Taking this function away was a poorly thought out decision and it should be added back.

1 Like

If it can tip the balance, might as well try!

I want to install the application “Automatic Ripping Machine” on my NAS. This application watches the CDROM drive and automatically rip music or movies. The problem is that, even if I mount the cdrom into the container, the running application does not have the permission to access it.

I have managed to chmod +444 /dev/sr0 to make it work but it does not survive a reboot. The cleanest solution would be to include my user into cdrom group, but I get the famous message “membership of this builtin group may not be altered”.

If the TrueNAS team could revisit their decision, or providing a way to achieve the same result, that would be awesome!

Hah - maybe this is why I could not get Automatic Ripping Machine to work, there is no access to /dev/sr0 by the apps user and I cannot add it to the cdrom group.

EDIT: No, chmod +444 /dev/sr0 did not fix my problems :frowning:

Fri Sep  5 13:47:43 CEST 2025 Entering docker wrapper
Fri Sep  5 13:47:43 CEST 2025 [ARM] Not CD, Blu-ray, DVD or Data. Bailing out on sr0
Fri Sep  5 13:47:45 CEST 2025 Entering docker wrapper
Fri Sep  5 13:47:45 CEST 2025 [ARM] Not CD, Blu-ray, DVD or Data. Bailing out on sr0
Fri Sep  5 13:47:55 CEST 2025 Entering docker wrapper
Fri Sep  5 13:47:56 CEST 2025 [ARM] Starting ARM for DVD on sr0

I mostly use ARM for music, but the issue I’m facing is that the UI does not shows any drives, but I figured out a “little dance” to make it show up and rip audio CDs.

EDIT: No, chmod +444 /dev/sr0 did not fix my problems :frowning:

No, you’re right. I was on a false track. I opened a bug into the app git repository (Issue 3126). As I said in the bug report, I managed to make the rip work without changing anything on permissions. This leads me to believe that we are not experiencing the same issue.

According to the logs you show, ARM is not able to determine the type of the disc you entered. Have you tried a different movie?

I tried a different one - same issue. Here someone suggests a very peculiar method to solve this issue. Since the TrueNas app does not really allow me to set the --cap-add docker flag I am not sure if this is possible Disk is not found · automatic-ripping-machine/automatic-ripping-machine · Discussion #1551 · GitHub