[SOLVED] LXC Container “Permission Denied” — Dataset Owned by UID 2147000035

TrueNAS General
1

I was setting up a Proxmox Backup Server (PBS) LXC container on TrueNAS SCALE and hit a wall:
Every time I tried to use a mounted ZFS dataset in the container, I got “permission denied” errors—even though the dataset existed and was mounted correctly.

The culprit?
The dataset’s owner and group were set to 2147000035, which is a Windows ACL “synthetic” user/group—not a real Unix user. This happens if you create datasets with the default Windows ACLs in TrueNAS.

LXC containers (and their apps) have no idea who UID/GID 2147000035 is, so all writes fail.

How I Fixed It:

  1. Edit the dataset ACL:
    Changed ACL Type to POSIX in TrueNAS UI.
  2. Change owner/group:
    Set User/Group to a real user inside the container (I used backup for PBS).
  3. Apply recursively and restart the container.

Result:
Writes worked immediately—no more permission errors.

Bottom line:
If you’re mounting a dataset with LXC on TrueNAS and see UID/GID 2147000035,
switch to POSIX ACLs and set a real Unix user as owner.
Otherwise, your container can’t write!

1 Like
2

Hmm…I haven’t seen this before. Can you provide more information? Your solution will basically nuke any existing permissions. It’s better to see if there’s an actual bug and fix it.

3

Thanks for looking into this! Here’s what I’m seeing on my setup:

On the TrueNAS SCALE host (/mnt/tank/pbs):

drwxrwx---     5 2147000035 2147000035     6 Aug  1 21:02 .
drwxr-xr-x    14 root       root          14 Aug  1 19:07 ..
drwxr-x--- 65538 2147000035 2147000035 65538 Aug  1 20:37 .chunks
-rw-r--r--     1 2147000035 2147000035     0 Aug  1 20:37 .lock
drwxr-xr-x     3 2147000035 2147000035     3 Aug  1 21:00 ct
drwxr-xr-x     5 2147000035 2147000035     5 Aug  1 21:10 vm

Inside the PBS LXC (/backup):

drwxrwx---     5 backup backup     6 Aug  2 02:02 .
drwxr-xr-x    18 root   root      22 Aug  1 15:12 ..
drwxr-x--- 65538 backup backup 65538 Aug  2 01:37 .chunks
drwxr-xr-x     3 backup backup     3 Aug  2 02:00 ct
-rw-r--r--     1 backup backup     0 Aug  2 01:37 .lock
drwxr-xr-x     5 backup backup     5 Aug  2 02:10 vm
  • The backup user/group inside the container is mapped to UID/GID 2147000035 on the host, via the LXC idmap.
  • If I set the backup user inside PBS to anything else, I hit permission errors on the mounted dataset.

This seems to be how TrueNAS handles permissions for datasets with “owner@” (looks like some internal high UID).
I’m not changing ownership—just making sure the container’s backup user matches that UID.

If there’s a “right way” to handle this without aligning UIDs, I’m definitely interested!
But in my case, using UID 2147000035 was the only thing that actually worked.

Let me know if you want zfs get or ACL output for the dataset. Happy to help debug further if this isn’t expected.

1 Like
4

Follow-up (re-fix):

I ended up having to redo this after some changes, so here’s the exact process that worked again to get PBS writing to the dataset cleanly from the LXC.

Steps

1. Stop the container:

incus stop pbs

2. Reset and apply a persistent raw.idmap so that both root (0) and backup (34) map directly host ↔ container:

incus config set pbs raw.idmap "uid 0 0
gid 0 0
uid 34 34
gid 34 34"

3. Start it back up:

incus start pbs

4. Verify inside the container:

id backup
# uid=34(backup) gid=34(backup) groups=34(backup),26(tape)

sudo -u backup touch /backup/testfile
ls -l /backup
# -rw-rw-r-- 1 backup backup 0 Sep 18 21:20 testfile

Verify on the host

incus config show pbs --expanded | grep -A5 idmap
  raw.idmap: |-
    uid 0 0
    gid 0 0
    uid 34 34
    gid 34 34

Result

The dataset (/mnt/dagda/pbs on the host, mounted as /backup inside) stays owned by UID/GID 34, which matches PBS’s backup account. No more nobody/nogroup, and the mapping survives restarts.

Gotchas

  • Flipping the container to privileged breaks the mapping.
  • Editing userns_idmap via midclt overwrote the clean config and caused validation errors.
  • Always stop the container before applying raw.idmap changes.