Это первый результат в Google по запросу: proxmox backup tar cannot open permission denied. Изменение прав доступа, как было предложено, снова сделало резервное копирование возможным. Спасибо, что опубликовали решение! Дополнение: я подал отчет об ошибке здесь: Bug 1834

Привет, такая же проблема здесь на Proxmox 5.4! Команда tar, используемая для резервного копирования, похоже, не работает напрямую с NFS-точкой монтирования. Самое простое решение для меня было изменить tmpdir на /tmp по умолчанию в /etc/vzdump.conf: grep -e "^tmpdir" /etc/vzdump.conf || \ cat <<EOF >> /etc/vzdump.conf tmpdir: /tmp EOF. С уважением.

Нужно установить права chmod и на точку монтирования: Код: # lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/backup-1 ls: невозможно открыть директорию '/mnt/pve/backup-1': Доступ запрещен

# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/ ... drwxrwxrwx 4 root 1001 4096 1 ноя 2017 backup drwxrwxrwx 5 root root 4096 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 1 ноя 2017 backup-1 drwxr-xr-x 5 nobody nogroup 4096 28 июл 2017 backup-2

# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/pve/backup-1 всего 32 drwxr-xr-x 4 nobody nogroup 4096 1 ноя 2017 . drwxr-xr-x 7 nobody nogroup 4096 18 июн 18:09 .. drwxr-xr-x 2 nobody nogroup 20480 25 июн 16:33 dump

точно моя проблема: я поменял mybackup на NFS-ресурс в сети и скопировал туда свои старые дампы. Но с новыми он не работает. Я уже изменил права, но не могу заставить это работать. Код: root@pve:/mnt/pve# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- ls -la /mnt/ всего 20 drwxrwxrwx 5 nobody nogroup 4096 10 авг 13:08 . drwxr-xr-x 22 nobody nogroup 4096 27 янв 2019 .. drwxr-xr-x 2 nobody nogroup 4096 28 июл 21:28 backup drwxrwxrwx 4 nobody nogroup 4096 10 авг 12:35 pve drwxr-xr-x 2 nobody nogroup 4096 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/ всего 20 drwxrwxrwx 4 nobody nogroup 4096 10 авг 12:35 . drwxrwxrwx 5 nobody nogroup 4096 10 авг 13:08 .. drwxrwxrwx 7 nobody nogroup 4096 10 авг 12:59 storage drwxr-xr-x 8 nobody nogroup 4096 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/ всего 32 drwxr-xr-x 8 nobody nogroup 4096 10 авг 17:04 . drwxrwxrwx 4 nobody nogroup 4096 10 авг 12:35 .. drwxr-xr-x 2 nobody nogroup 4096 10 авг 16:54 backup drwxrwxrwx 3 nobody nogroup 4096 10 авг 17:24 dump drwxrwxrwx 2 nobody nogroup 4096 10 авг 12:35 images drwxr-xr-x 2 nobody nogroup 4096 10 авг 17:04 privat drwxrwxrwx 4 nobody nogroup 4096 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/ всего 50983828 drwxrwxrwx 3 nobody nogroup 4096 10 авг 17:24 . drwxr-xr-x 8 nobody nogroup 4096 10 авг 17:04 .. drwxrwxrwx 2 nobody nogroup 4096 10 авг 12:59 @eaDir -rw-r--r-- 1 nobody nogroup 1449 10 авг 13:08 vzdump-lxc-105-2019_08_10-13_08_02.log -rw-r--r-- 1 nobody nogroup 4272 10 авг 14:38 vzdump-lxc-105-2019_08_10-13_36_23.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 15:16 vzdump-lxc-105-2019_08_10-15_16_13.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 16:51 vzdump-lxc-105-2019_08_10-16_51_36.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 17:05 vzdump-lxc-105-2019_08_10-17_04_58.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 17:09 vzdump-lxc-105-2019_08_10-17_09_15.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 17:12 vzdump-lxc-105-2019_08_10-17_12_41.log -rw-r--r-- 1 nobody nogroup 1449 10 авг 17:24 vzdump-lxc-105-2019_08_10-17_24_17.log ---------- 1 nobody nogroup 19155222243 21 июн 18:47 vzdump-qemu-100-2019_06_21-17_41_09.vma.gz ---------- 1 nobody nogroup 13321 28 июл 22:32 vzdump-qemu-100-2019_07_28-21_47_15.log ---------- 1 nobody nogroup 25437095590 28 июл 22:32 vzdump-qemu-100-2019_07_28-21_47_15.vma.gz ---------- 1 nobody nogroup 11371 21 июн 15:42 vzdump-qemu-102-2019_06_20-22_06_29.vma.log ---------- 1 nobody nogroup 6288048319 21 июн 15:42 vzdump-qemu-102-2019_06_20-22_06_29.vma.lzo -rw-r--r-- 1 nobody nogroup 3173 28 июл 21:26 vzdump-qemu-103-2019_07_28-21_25_33.log -rw-r--r-- 1 nobody nogroup 1326948231 28 июл 21:26 vzdump-qemu-103-2019_07_28-21_25_33.vma.lzo Вот вывод из веб-интерфейса Код: INFO: запускается новая задача резервного копирования: vzdump 105 --compress lzo --remove 0 --storage storage-lan --mode stop --node pve INFO: Запуск резервного копирования ВМ 105 (lxc) INFO: Резервное копирование начато в 2019-08-10 17:24:17 INFO: статус = запущено INFO: режим резервного копирования: остановка INFO: приоритет ionice: 7 INFO: Имя CT: docker-rwar INFO: остановка ВМ INFO: создание архива '/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: Не удалось открыть: Доступ запрещен INFO: tar: Ошибка неустранимая: выходим теперь INFO: перезапуск ВМ INFO: гость снова в сети через 11 секунд ERROR: Резервное копирование ВМ 105 не удалось - команда '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' завершилась ошибкой: код выхода 2 INFO: Провал в 2019-08-10 17:24:28 INFO: Задача резервного копирования закончилась с ошибками TASK ERROR: ошибки задания вот мой /etc/exports Код: /volume3/NetBackup proxmox(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100) есть ли идеи, что еще я мог бы попробовать?

Я все еще сталкиваюсь с этой ошибкой, используя Proxmox 6.2, в следующей среде: - 2 SATA диска по 1 ТБ с mdadm RAID 1, содержащие два ЛВ, -- один lvm-thin на 800 ГБ -- один lvm с разделом ext4, смонтированный как резервное хранилище. Во время создания резервных копий из QEMU-VM всё проходит нормально, но останавливается на контейнерах LXC. Если я переключаю резервное копирование на любое другое хранилище, всё работает нормально. Изменение файла vzdump.conf с настройкой tmpdir: /tmp позволяет резервному копированию LXC на точку монтирования /backup. Для справки: VMID НАЗВАНИЕ СТАТУС ВРЕМЯ РАЗМЕР ИМЯ ФАЙЛА 110 ltsc OK 00:07:44 10.66GB /root/backup/vz/dump/vzdump-qemu-110-2020_05_15-11_12_35.vma.zst 111 mint OK 00:05:01 6.54GB /root/backup/vz/dump/vzdump-qemu-111-2020_05_15-11_20_19.vma.zst 138 vmbase OK 00:01:10 1.13GB /root/backup/vz/dump/vzdump-qemu-138-2020_05_15-11_25_20.vma.zst 200 ucs OK 00:02:11 2.16GB /root/backup/vz/dump/vzdump-qemu-200-2020_05_15-11_26_30.vma.zst 202 fog OK 00:01:01 1.13GB /root/backup/vz/dump/vzdump-qemu-202-2020_05_15-11_28_41.vma.zst 221 pfsense OK 00:00:58 664MB /root/backup/vz/dump/vzdump-qemu-221-2020_05_15-11_29_42.vma.zst 300 dbn10 FAILED 00:00:01 команда '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' завершилась с кодом 2 301 ftp FAILED 00:00:01 команда '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' завершилась с кодом 2 302 guacamole FAILED 00:00:01 команда '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' завершилась с кодом 2 303 pihole FAILED 00:00:02 команда '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' завершилась с кодом 2 304 unifi FAILED 00:00:02 команда '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' завершилась с кодом 2 305 elk FAILED 00:00:00 команда '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' завершилась с кодом 2 306 netbox FAILED 00:00:01 команда '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' завершилась с кодом 2 ИТОГО 00:18:13 22.27GB

в общем, работа lzo была явной случайностью. основная проблема здесь заключается в том, что у непривилегированных пользователей нет возможности создать временный каталог в целевом хранилище; в случае с NFS сервер nfs должен сделать "root_squash" в своих экспортах, чтобы обойти это. (по крайней мере, это решение "работает для нас")

год 2023.....версия proxmox 7.3.6 и та же проблема все еще продолжается. Никогда не использовал CT до сих пор, только ВМ (могу подтвердить, что резервные копии для ВМ на удаленное хранилище nfs работают, а вот для CT — нет, то есть lzo работает, но резервные копии .zst — нет), поэтому я только что заметил проблему с ошибкой отказа в доступе, когда пытался создать резервную копию CT на удаленное хранилище (из TrueNAS scale) в качестве общего ресурса nfs. Если это имеет значение для кого-то, то, когда я в первый раз добавлял это хранилище из опций датацентра, я выбрал только VZDump backup file в качестве содержимого и ничего больше. Я тогда подумал, что, чтобы создавать резервные копии CT, возможно, нужно выбрать другой тип содержимого. Это не так, правда? Затем, согласно рекомендации из другого поста, который я нашел, я проверил права доступа к моим путям, с такими результатами: /mnt/pve/ Код: Файл: /mnt/pve
Размер: 7 Блоков: 3 IO Блок: 512 каталог
Устройство: 1ah/26d Идентификатор: 132769 Ссылки: 7
Доступ: (0755/drwxr-xr-x) UID: (0/ root) GID: (0/ root)
Доступ: 2022-05-27 15:11:49.914000723 +0300
Изменён: 2022-11-30 00:07:21.540404665 +0200
Изменено: 2022-11-30 00:07:21.540404665 +0200
Создан: 2022-05-27 15:11:49.914000723 +0300 /mnt/pve/TruenasBackup Код: Файл: /mnt/pve/TruenasBackup/
Размер: 3 Блоков: 1 IO Блок: 1048576 каталог
Устройство: 34h/52d Идентификатор: 34 Ссылки: 3
Доступ: (0770/drwxrwx---) UID: (1000/ geo) GID: (1000/ geo)
Доступ: 2022-11-27 00:01:12.123218852 +0200
Изменён: 2022-11-27 01:25:22.735805798 +0200
Изменено: 2022-11-27 01:25:22.735805798 +0200 /mnt/pve/TruenasBackup/dump Код: Файл: /mnt/pve/TruenasBackup/dump
Размер: 22 Блоков: 97 IO Блок: 1048576 каталог
Устройство: 34h/52d Идентификатор: 2 Ссылки: 2
Доступ: (0755/drwxr-xr-x) UID: (1000/ geo) GID: (1000/ geo)
Доступ: 2022-11-27 01:25:22.735805798 +0200
Изменён: 2023-03-15 15:04:47.173258843 +0200
Изменено: 2023-03-15 15:04:47.173258843 +0200 Но согласно правам доступа в Linux для 200 и 300 смотрите ниже ........ Код: Chmod 200 (chmod a+rwx,u-rx,g-rwx,o-rwx) устанавливает права так, что (U) пользователь / владелец не может читать, может писать, но не может выполнять. (G) группа не может читать, не может писать и не может выполнять. (O) другие не могут читать, не могут писать и не могут выполнять.

Chmod 300 (chmod a+rwx,u-r,g-rwx,o-rwx) устанавливает права так, что (U) пользователь / владелец не может читать, может писать и может выполнять. (G) группа не может читать, не может писать и не может выполнять. (O) другие не могут читать, не могут писать и не могут выполнять. .... обе 200 и 300 позволяют пользователю писать, так почему у меня возникли проблемы с доступом? В конце концов, я пытался решить проблему со стороны Truenas, сопоставив всех пользователей с root (не совсем, см. ниже) в рамках конфигурации NFS с одной особенностью. Хотя я использовал опции Mapall User и Mapall Group вместо Maproot User и Maproot Group, я использовал другое имя для этого пользователя, созданного внутри Truenas, например trueuser. Это сработало, но я не понимаю, почему (используя другое имя, чем root) и не знаю, какие проблемы с безопасностью эта мера может вызвать. Все мои соображения отмечены темно-красным.