Habe als root trotzdem permission denied

[Peleke]

In einer LXC unter proxmox mit Debian 13 habe ich das Problem, dass ich trotz angemeldetem root Nutzer bei allen root-Berechtigung (z. B. bei apt upgrade) einen permission denied Fehler bekomme und auch nicht in /home Verzeichnis darf:

Unable to create directory /root/.local/share/nano/: Permission denied
It is required for saving/loading search history or cursor positions.

root@debian:/# ls -la
total 68
drwxr-xr-x 19 root root 4096 Nov 10 14:34 .
drwxr-xr-x 19 root root 4096 Nov 10 14:34 ..
lrwxrwxrwx 1 root root 7 Aug 24 18:20 bin -> usr/bin
drwxr-xr-x 2 root root 4096 Aug 24 18:20 boot
drwxr-xr-x 6 root root 480 Nov 10 14:34 dev
drwxr-xr-x 85 root root 4096 Nov 10 14:39 etc
drwxr-xr-x 4 root root 4096 Nov 10 11:54 home
lrwxrwxrwx 1 root root 7 Aug 24 18:20 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Oct 1 16:43 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Aug 24 18:20 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Oct 1 16:43 libx32 -> usr/libx32
drwx------ 2 nobody nogroup 16384 Oct 18 08:13 lost+found
drwxr-xr-x 3 root root 4096 Oct 18 22:29 media
drwxr-xr-x 2 root root 4096 Oct 1 16:43 mnt
drwxr-xr-x 4 root root 4096 Oct 18 11:05 nix
drwxr-xr-x 3 root root 4096 Nov 10 12:00 opt
dr-xr-xr-x 302 nobody nogroup 0 Nov 10 14:34 proc
drwx------ 5 nobody root 4096 Oct 18 22:30 root
drwxr-xr-x 17 root root 540 Nov 10 14:35 run
lrwxrwxrwx 1 root root 8 Aug 24 18:20 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Oct 1 16:43 srv
dr-xr-xr-x 13 nobody nogroup 0 Nov 10 14:34 sys
drwxrwxrwt 7 root root 140 Nov 10 14:38 tmp
drwxr-xr-x 14 root root 4096 Oct 1 16:43 usr
drwxr-xr-x 11 root root 4096 Oct 18 08:13 var
root@debian:/# cd /root/
-bash: cd: /root/: Permission denied
root@debian:/# mount
/dev/mapper/pve-vm--102--disk--0 on / type ext4 (rw,relatime,stripe=16)
/dev/disk/by-id/usb-Samsung_Flash_Drive_0340318080003148-0:0-part1 on /home/pyload/Downloads type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
none on /dev type tmpfs (rw,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys/net type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,relatime)
proc on /proc/sysrq-trigger type proc (ro,relatime)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
sysfs on /sys/devices/virtual/net type sysfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
proc on /dev/.lxc/proc type proc (rw,relatime)
sys on /dev/.lxc/sys type sysfs (rw,relatime)
none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
lxcfs on /proc/cpuinfo type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/diskstats type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/loadavg type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/meminfo type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/slabinfo type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/stat type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/swaps type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /proc/uptime type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
lxcfs on /sys/devices/system/cpu type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
udev on /dev/full type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
udev on /dev/null type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
udev on /dev/random type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
udev on /dev/tty type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
udev on /dev/urandom type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
udev on /dev/zero type devtmpfs (rw,nosuid,relatime,size=8087604k,nr_inodes=2021901,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
devpts on /dev/ptmx type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
devpts on /dev/tty1 type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
devpts on /dev/tty2 type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
none on /proc/sys/kernel/random/boot_id type tmpfs (ro,nosuid,nodev,noexec,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,uid=100000,gid=100000,inode64)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=3252820k,nr_inodes=819200,mode=755,uid=100000,gid=100000,inode64)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,uid=100000,gid=100000,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,uid=100000,gid=100000,inode64)
ramfs on /run/credentials/systemd-journald.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)
ramfs on /run/credentials/systemd-networkd.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)
ramfs on /run/credentials/container-getty@2.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)
ramfs on /run/credentials/console-getty.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)
ramfs on /run/credentials/container-getty@1.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)

Wodran kann das liegen und wie kann ich das beheben?

 

[nebulein]

Was passiert wenn du ein "su" davor schreibst?

 

[BoeserBrot]

Besagte Ordner irgendwie als RO (read only) eingebunden?

 

[Uridium]

Wenn es ein "unprivileged" Container ist, könnten die UIDs nicht stimmen.

 

[kieleich]

vielleicht doch nicht root. du kannst zB auch als normaler user, dich mit 'unshare -r' zum root machen aber trotzdem nicht auf /root/ zu greifen weil du halt doch, nicht root bist

und es sieht dann genau so aus wie bei dir, im 'ls' gehört /root dann auf einmal "nobody"

namespaces unter linux sind komisch

 

[CoMo]

Wenn es ein "unprivileged" Container ist, könnten die UIDs nicht stimmen.

Korrekt. Du bist nur scheinbar root im Container. Auf dem Host bist du ein normaler unprivilegierter Benutzer.

Öffne eine Shell auf dem Host, navigiere in das Volume des Containers und schau dir dort die Berechtigungen und den Besitz an.

 

[Peleke]

Habe das Problem jertzt lösen können:

• Container stoppen.
• Auf dem PVE-Host mounten:
  pct mount <CTID>
  
  
  
  
• Ownership korrigieren (mapped root = 100000):
  chown -R 100000:0 /var/lib/lxc/<CTID>/rootfs/root
  chown 100000:0 /var/lib/lxc/<CTID>/rootfs
  chmod 700 /var/lib/lxc/<CTID>/rootfs/root
  
  
  
  
• Container unmounten & starten:
  pct unmount <CTID>
  pct start <CTID>

 

[Uridium]

Geändert werden sollte auf 100000:100000. Dann auch nicht absolut, sondern relativ. Ist ja nicht alles '0'. Dafür gibt es z.B. "uidmapshift" (nsexec-bzr).

Der Container dürfte aber jetzt sowieso schon kaputt sein, weil Du alles auf '0' gesetzt hast.
Edit: Obwohl... alles hast Du ja nicht neu gesetzt. Aber es fehlen einige Ordner und das System ist bereits teilweise korrigiert (/root). Alles durcheinander jetzt. Wobei uidmapshift das nach wie vor korrigieren kann.

Wenn der Container noch unmodifiziert ist, setz ihn einfach neu auf, von vornherein als unprivileged.

Im jetzigen Zustand dürften z.B. Updates nicht funktionieren.