[SOLVED] Create backup fail with error: Cannot open: Permission de

Alibek

Well-Known Member
Jan 13, 2017
100
14
58
44
Summary:
pve-manager/4.4-5/c43015a5 (running kernel: 4.4.35-2-pve)
The node have attached storage by NFS (it will use for vzdump backups) with mount point /mnt/pve/backup-1
When pve try to create backup it fail with error:
Code:
INFO: starting new backup job: vzdump 111 --compress lzo --node lpr8 --mode stop --storage backup-1 --remove 0
INFO: Starting Backup of VM 111 (lxc)
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: dhcp1-internal
INFO: stopping vm
INFO: creating archive '/mnt/pve/backup-1/dump/vzdump-lxc-111-2017_01_27-16_54_45.tar.lzo'
INFO: tar: /mnt/pve/backup-1/dump/vzdump-lxc-111-2017_01_27-16_54_45.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
...

Cause:
created path (by WebUI) have wrong permission
Code:
root@lpr8:~# stat /mnt/pve/
  File: ‘/mnt/pve/’
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: fb02h/64258d    Inode: 274776      Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-01-26 18:25:35.785079873 +0300
Modify: 2017-01-26 18:19:33.143166609 +0300
Change: 2017-01-26 18:19:33.143166609 +0300
Birth: -
root@lpr8:~# stat /mnt/pve/backup-1/
  File: ‘/mnt/pve/backup-1/’
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: 46h/70d    Inode: 805340056   Links: 3
Access: (0000/d---------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-01-26 18:25:35.943993849 +0300
Modify: 2017-01-26 18:19:33.233542129 +0300
Change: 2017-01-26 18:19:33.233542129 +0300
Birth: -
root@lpr8:~# stat /mnt/pve/backup-1/dump/
  File: ‘/mnt/pve/backup-1/dump/’
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: 46h/70d    Inode: 805339373   Links: 2
Access: (0000/d---------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-01-26 18:30:07.673851875 +0300
Modify: 2017-01-26 18:29:04.528812928 +0300
Change: 2017-01-26 18:29:04.528812928 +0300

Then tar running under UID 100000 and of cause can't write to /mnt/pve/backup-1/dump/
Code:
100000    86811  86809 22 17:01 ?        00:00:01 tar cpf - --totals --sparse --numeric-owner --acls --xattrs --xattrs-include=user.* --xattrs-include=security.capability --warning=no-xattr-write --one-file-system --warning=no-file-ignored --directory=/mnt/pve/backup-1/dump/vzdump-lxc-111-2017_01_27-17_01_11.tmp ./etc/vzdump/pct.conf --directory=/mnt/vzsnap0 --no-anchored --exclude=lost+found --anchored --exclude=./tmp/?* --exclude=./var/tmp/?* --exclude=./var/run/?*.pid ./

Decision:
change permission on dirs /mnt/pve/{backup-1,backup}/dump}:
Code:
chmod 755 /mnt/pve/{backup-1,backup}/dump}

UPD 2019-06-26: need set chmod 755 on mountpoint too:
Code:
chmod 755 /mnt/pve/{backup-1,backup}

Conclusion:
This is bug - tools for making backups, must be set the correct permissions on the working directories.
 
Last edited:
This is the first result on Google for: proxmox backup tar cannot open permission denied
Changing permissions as suggested made the backup work again. Thanks for posting the solution!

Edit: I've filed a bug report here:
Bug 1834
 
Last edited:
Hi,

same problem here on Proxmox 5.4 !

The tar command used for the backups doesn't seem to work directly to an NFS mount point.

The easiest solution for me was to change the tmpdir to /tmp by default in /etc/vzdump.conf

grep -e "^tmpdir" /etc/vzdump.conf || \
cat <<EOF >> /etc/vzdump.conf
tmpdir: /tmp
EOF

regards
 
Need set chmod permission on mountpoint too:
Code:
# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/backup-1
ls: cannot open directory '/mnt/pve/backup-1': Permission denied

# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/
...
drwxrwxrwx 4 root 1001 4096 Nov  1  2017 backup
drwxrwxrwx 5 root root 4096 Jul 28  2017 backup-1

# chmod 755 /mnt/pve/{backup-1,backup}
# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/
...
drwxr-xr-x 4 nobody nogroup 4096 Nov  1  2017 backup-1
drwxr-xr-x 5 nobody nogroup 4096 Jul 28  2017 backup-2

# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/backup-1
total 32
drwxr-xr-x 4 nobody nogroup  4096 Nov  1  2017 .
drwxr-xr-x 7 nobody nogroup  4096 Jun 18 18:09 ..
drwxr-xr-x 2 nobody nogroup 20480 Jun 25 16:33 dump
 
Hi,

same problem here on Proxmox 5.4 !

The tar command used for the backups doesn't seem to work directly to an NFS mount point.

The easiest solution for me was to change the tmpdir to /tmp by default in /etc/vzdump.conf

grep -e "^tmpdir" /etc/vzdump.conf || \
cat <<EOF >> /etc/vzdump.conf
tmpdir: /tmp
EOF

regards
This variant not work if backup biggest then space in /tmp
 
This variant not work if backup biggest then space in /tmp

exactly my problem: I changed mybackup to NFS share in the network and copied my old dumps there.

but it can do it with the new ones. changed already the permissions but i dont get it working.

Code:
root@pve:/mnt/pve# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/
total 20
drwxrwxrwx  5 nobody nogroup 4096 Aug 10 13:08 .
drwxr-xr-x 22 nobody nogroup 4096 Jan 27  2019 ..
drwxr-xr-x  2 nobody nogroup 4096 Jul 28 21:28 backup
drwxrwxrwx  4 nobody nogroup 4096 Aug 10 12:35 pve
drwxr-xr-x  2 nobody nogroup 4096 Aug 10 13:08 vzsnap0
root@pve:/mnt/pve#
root@pve:/mnt/pve# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/
total 20
drwxrwxrwx 4 nobody nogroup 4096 Aug 10 12:35 .
drwxrwxrwx 5 nobody nogroup 4096 Aug 10 13:08 ..
drwxrwxrwx 7 nobody nogroup 4096 Aug 10 12:59 storage
drwxr-xr-x 8 nobody nogroup 4096 Aug 10 17:04 storage-lan
root@pve:/mnt/pve# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/storage-lan/
total 32
drwxr-xr-x 8 nobody nogroup 4096 Aug 10 17:04 .
drwxrwxrwx 4 nobody nogroup 4096 Aug 10 12:35 ..
drwxr-xr-x 2 nobody nogroup 4096 Aug 10 16:54 backup
drwxrwxrwx 3 nobody nogroup 4096 Aug 10 17:24 dump
drwxrwxrwx 2 nobody nogroup 4096 Aug 10 12:35 images
drwxr-xr-x 2 nobody nogroup 4096 Aug 10 17:04 privat
drwxrwxrwx 4 nobody nogroup 4096 Aug 10 12:35 template
root@pve:/mnt/pve# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/storage-lan/dump/
total 50983828
drwxrwxrwx 3 nobody nogroup        4096 Aug 10 17:24 .
drwxr-xr-x 8 nobody nogroup        4096 Aug 10 17:04 ..
drwxrwxrwx 2 nobody nogroup        4096 Aug 10 12:59 @eaDir
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 13:08 vzdump-lxc-105-2019_08_10-13_08_02.log
-rw-r--r-- 1 nobody nogroup        4272 Aug 10 14:38 vzdump-lxc-105-2019_08_10-13_36_23.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 15:16 vzdump-lxc-105-2019_08_10-15_16_13.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 16:51 vzdump-lxc-105-2019_08_10-16_51_36.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 17:05 vzdump-lxc-105-2019_08_10-17_04_58.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 17:09 vzdump-lxc-105-2019_08_10-17_09_15.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 17:12 vzdump-lxc-105-2019_08_10-17_12_41.log
-rw-r--r-- 1 nobody nogroup        1449 Aug 10 17:24 vzdump-lxc-105-2019_08_10-17_24_17.log
---------- 1 nobody nogroup 19155222243 Jun 21 18:47 vzdump-qemu-100-2019_06_21-17_41_09.vma.gz
---------- 1 nobody nogroup       13321 Jul 28 22:32 vzdump-qemu-100-2019_07_28-21_47_15.log
---------- 1 nobody nogroup 25437095590 Jul 28 22:32 vzdump-qemu-100-2019_07_28-21_47_15.vma.gz
---------- 1 nobody nogroup       11371 Jun 21 15:42 vzdump-qemu-102-2019_06_20-22_06_29.vma.log
---------- 1 nobody nogroup  6288048319 Jun 21 15:42 vzdump-qemu-102-2019_06_20-22_06_29.vma.lzo
-rw-r--r-- 1 nobody nogroup        3173 Jul 28 21:26 vzdump-qemu-103-2019_07_28-21_25_33.log
-rw-r--r-- 1 nobody nogroup  1326948231 Jul 28 21:26 vzdump-qemu-103-2019_07_28-21_25_33.vma.lzo

Here the output from the webgui

Code:
INFO: starting new backup job: vzdump 105 --compress lzo --remove 0 --storage storage-lan --mode stop --node pve
INFO: Starting Backup of VM 105 (lxc)
INFO: Backup started at 2019-08-10 17:24:17
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: docker-rwar
INFO: stopping vm
INFO: creating archive '/mnt/pve/storage-lan/dump/vzdump-lxc-105-2019_08_10-17_24_17.tar.lzo'
INFO: tar: /mnt/pve/storage-lan/dump/vzdump-lxc-105-2019_08_10-17_24_17.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
INFO: restarting vm
INFO: guest is online again after 11 seconds
ERROR: Backup of VM 105 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/storage-lan/dump/vzdump-lxc-105-2019_08_10-17_24_17.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | lzop >/mnt/pve/storage-lan/dump/vzdump-lxc-105-2019_08_10-17_24_17.tar.dat' failed: exit code 2
INFO: Failed at 2019-08-10 17:24:28
INFO: Backup job finished with errors
TASK ERROR: job errors

here my /etc/exports

Code:
/volume3/NetBackup      proxmox(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

any idea what else i could try?
 
found for myself a workaround to not use the no_root_squash option and put everyone on the same authorization level. depends on the environment if you can use this.

Regards
Seb
 
  • Like
Reactions: Alibek
Im still having this error, using proxmox 6.2, with this environment:

- 2 sata 1tb disks, with mdmadm raid1, serving two LVs,
-- one lvm-thin with 800gb
-- one lvm with ext4 partition, mounted as a backup storage

while making backups from qemu-vms evething goes fine, it stops on the lxc containers.
If I change the backup to any other storage, it will work normally

changing the vzdump.conf file with seting the tmpdir: /tmp allows the lxc to be backed up to the /backup mount point

For refference:



VMIDNAMESTATUSTIMESIZEFILENAME
110ltscOK00:07:44
10.66GB​
/root/backup/vz/dump/vzdump-qemu-110-2020_05_15-11_12_35.vma.zst
111mintOK00:05:01
6.54GB​
/root/backup/vz/dump/vzdump-qemu-111-2020_05_15-11_20_19.vma.zst
138vmbaseOK00:01:10
1.13GB​
/root/backup/vz/dump/vzdump-qemu-138-2020_05_15-11_25_20.vma.zst
200ucsOK00:02:11
2.16GB​
/root/backup/vz/dump/vzdump-qemu-200-2020_05_15-11_26_30.vma.zst
202fogOK00:01:01
1.13GB​
/root/backup/vz/dump/vzdump-qemu-202-2020_05_15-11_28_41.vma.zst
221pfsenseOK00:00:58
664MB​
/root/backup/vz/dump/vzdump-qemu-221-2020_05_15-11_29_42.vma.zst
300dbn10FAILED00:00:01command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-300-2020_05_15-11_30_40.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-300-2020_05_15-11_30_40.tar.dat' failed: exit code 2
301ftpFAILED00:00:01command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-301-2020_05_15-11_30_41.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-301-2020_05_15-11_30_41.tar.dat' failed: exit code 2
302guacamoleFAILED00:00:01command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-302-2020_05_15-11_30_42.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-302-2020_05_15-11_30_42.tar.dat' failed: exit code 2
303piholeFAILED00:00:02command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-303-2020_05_15-11_30_43.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-303-2020_05_15-11_30_43.tar.dat' failed: exit code 2
304unifiFAILED00:00:02command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-304-2020_05_15-11_30_45.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-304-2020_05_15-11_30_45.tar.dat' failed: exit code 2
305elkFAILED00:00:00command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-305-2020_05_15-11_30_47.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-305-2020_05_15-11_30_47.tar.dat' failed: exit code 2
306netboxFAILED00:00:01command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/root/backup/vz/dump/vzdump-lxc-306-2020_05_15-11_30_47.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/root/backup/vz/dump/vzdump-lxc-306-2020_05_15-11_30_47.tar.dat' failed: exit code 2
TOTAL​
00:18:1322.27GB
 
well during tests we see the same on pve 6.2-4;
backup seems to fail if the lxc is an unprivileged container;
seems to work if the lxs is a privileged container;

also this seems to happen only with zstd while lzo backups seem to work.

and I'm pretty confused about this :)
 
well during tests we see the same on pve 6.2-4;
backup seems to fail if the lxc is an unprivileged container;
seems to work if the lxs is a privileged container;

also this seems to happen only with zstd while lzo backups seem to work.

and I'm pretty confused about this :)

so basically lzo working was obviously an accident.

the main issue here is the unprivileged users not being able to create a temp dir at the destination storage;

in case of NFS the nfs-server should do a "root_squash" in its exports to work around this. (at least its a "works for us" solution)
 
i can confirm that changing the tmp DIR in /etc/vzdump.conf to another folder like the ZFS pool itself works great!
my config:

# vzdump default settings

tmpdir: /ZFS
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
#pigz: N
 
If anyone else wanders their way in here and the file permissions look fine, and you don't want to use a local temp dir, take a look at this post:

https://blog.doussan.info/posts/container-backup-permission-denied-nfs/

TL;DR - you want to swap your nfs share to map all users, rather than just the root user. In TrueNAS, you can change this on the NFS share under advanced -> access -> set mapall user to your nfs user, remove maproot user (leave it empty).
 
Last edited:
If anyone else wanders their way in here and the file permissions look fine, and you don't want to use a local temp dir, take a look at this post:

https://blog.doussan.info/posts/container-backup-permission-denied-nfs/

TL;DR - you want to swap your nfs share to map all users, rather than just the root user. In TrueNAS, you can change this on the NFS share under advanced -> access -> set mapall user to your nfs user, remove maproot user (leave it empty).

year 2023.....proxmox version 7.3.6 and the same issue still goes on.
Never used a CT up until now only VMs (I can confirm as well that backups to a remote nfs storage for Vms works not CTs though - so lzo works but not .zst backups), therefore I just noticed the problem with the denied permission error whilst trying to backup the CT to a remote storage (coming from TrueNAS scale) as an nfs share.

In case it matters to some, while adding that storage at first place from Datacenter options, I only chose for content VZDump backup file and nothing else. I thought then that in order to backup CTs maybe another type of content should be chosen. That isn t the case right?

Afterwards as per recommendation of another post I came across, I checked the permissions of my paths, with the below results:
/mnt/pve/
Code:
 File: /mnt/pve
  Size: 7               Blocks: 3          IO Block: 512    directory
Device: 1ah/26d Inode: 132769      Links: 7
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-05-27 15:11:49.914000723 +0300
Modify: 2022-11-30 00:07:21.540404665 +0200
Change: 2022-11-30 00:07:21.540404665 +0200
 Birth: 2022-05-27 15:11:49.914000723 +0300

/mnt/pve/TruenasBackup
Code:
 File: /mnt/pve/TruenasBackup/
  Size: 3               Blocks: 1          IO Block: 1048576 directory
Device: 34h/52d Inode: 34          Links: 3
Access: (0770/drwxrwx---)  Uid: ( 1000/     geo)   Gid: ( 1000/     geo)
Access: 2022-11-27 00:01:12.123218852 +0200
Modify: 2022-11-27 01:25:22.735805798 +0200
Change: 2022-11-27 01:25:22.735805798 +0200

/mnt/pve/TruenasBackup/dump
Code:
  File: /mnt/pve/TruenasBackup/dump
  Size: 22              Blocks: 97         IO Block: 1048576 directory
Device: 34h/52d Inode: 2           Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/     geo)   Gid: ( 1000/     geo)
Access: 2022-11-27 01:25:22.735805798 +0200
Modify: 2023-03-15 15:04:47.173258843 +0200
Change: 2023-03-15 15:04:47.173258843 +0200

But according to Linux permission for 200 and 300 see below ........
Code:
Chmod 200 (chmod a+rwx,u-rx,g-rwx,o-rwx) sets permissions so that, (U)ser / owner can't read, can write and can't execute. (G)roup can't read, can't write and can't execute. (O)thers can't read, can't write and can't execute.

Chmod 300 (chmod a+rwx,u-r,g-rwx,o-rwx) sets permissions so that, (U)ser / owner can't read, can write and can execute. (G)roup can't read, can't write and can't execute. (O)thers can't read, can't write and can't execute.


.... both 200 and 300 let the user write so why did I have permission problems ?

Finally I tried to solve the problem from Truenas side by mapping all users to root (not exactly, see below) as part of the NFS configuration with a difference. Even though I used Mapall User and Mapall Group options instead of Maproot User and Maproot Group, I used different name for that user created inside Truenas like trueuser.

It worked though, but I can t get why (using a different name than root) and i don t know what kind of security issues this action might have caused.


All my considerations are marked as dark red.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!