Unable to re-add apps to GID mapping for Incus

Here is an issue I am facing under 25.04: I’ve removed GID mapping for apps (568) by mistake in Incus (while removing other mappings).
However, I’m not unable to re-add that mapping.
When selecting the “apps” user, I get the following error:

 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.userns_idmap: User namespace idmaps may not be configured for builtin accounts.

Also, what’s weird is that after I close the dialog, and sometimes before, “apps” will change to 93 on its own.


Is there a way to change to restore the defaults any other way?
Is this a bug or intentional?
Jira report:
https://ixsystems.atlassian.net/browse/NAS-135475

1 Like

I’m not sure I follow this bit, but regardless I’d say submit a bug report. If you’re not allowed to create ID mapping for built in accounts, then you should probably be prevented from deleting the default also.

To illustrate. It just does this on its own:
Kooha-2025-04-21-22-10-11
Will file a bug report soon.

1 Like

Odd, I’m seeing that too and only for the apps group (not user) as far as I can tell. Make sure you mention both issues in the bug report and add the ticket to your comment when it’s available.

Jira Issue:
https://ixsystems.atlassian.net/browse/NAS-135475

2 Likes

I tried removing this from stable using midclt and it doesn’t allow it. I think it did allow it in RC.1, so that might be a pain to get back…

I’ve never run RC.1 personally, maybe the issue is specific to webui?
Also, would you mind sharing the command you’ve used for midctl? I’m struggling to find where the Incus stuff is hidden there. I will try re-adding that way maybe?

I’m experiencing the same issues so my container cannot read the folders or files assigned to apps

If you can, please leave this comment on Jira as well
https://ixsystems.atlassian.net/browse/NAS-135475

The issue was closed but I don’t see any reference in the PR for a remedy for users who have already encountered this issue.
Is this just not going to be addressed for those who are already affected? Is there no way for me to fix my broken configuration?
https://ixsystems.atlassian.net/browse/NAS-135475

This was a validation escape that it was possible. The fix was to plug the hole. If you already managed to remove the access for the apps group you’ll have to manually fix the database via sqlite3 command, the number of affected users on 25.04.0 doesn’t really reach the point where we’d write a migration to re-add the group mapping.

Warning: mildly tested SQL:

sqlite3 /data/freenas-v1.db 'UPDATE account_bsdgroups SET bsdgrp_userns_idmap="DIRECT" WHERE bsdgrp_gid=568;'
1 Like

That actually worked!
Thank you very much for spending time to help me with this. I’m really grateful.