LXC Backup to Synology NFS Fails with "Permission Denied"—But Only for Unprivileged Containers

Suatu pagi saya menemukan backup terjadwal di Proxmox berjalan dengan status job errors. Anehnya, tidak semua container gagal — ada satu yang tetap sukses seperti biasa. Tulisan ini mendokumentasikan proses menemukan penyebabnya, yang ternyata bukan di Proxmox sama sekali.

---

Lingkungan

Komponen	Keterangan
Hypervisor	Proxmox VE 8.4.0, node proxmox
Storage backup 1	NFS ke Synology (192.168.xx.xx:/volume1/lokal-nas-fkuh)
Storage backup 2	NFS ke TrueNAS (192.168.22.xx:/mnt/pool1/...)
Container	CT 100 progress3, CT 103 Pak, CT 116 osce
Job	vzdump 100 103 116 --storage synology --mode snapshot --compress zstd

---

Gejala

Backup terjadwal gagal sebagian. Berikut potongan log aslinya:

INFO: starting new backup job: vzdump 100 103 116 --storage synology ...
INFO: Starting Backup of VM 100 (lxc)
INFO: CT Name: progress3
INFO: creating vzdump archive '/mnt/pve/synology/dump/vzdump-lxc-100-2026_08_23-21_00_00.tar.zst'
INFO: tar: /mnt/pve/synology/dump/vzdump-lxc-100-2026_08_23-21_00_00.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
ERROR: Backup of VM 100 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - ...' failed: exit code 2

INFO: Starting Backup of VM 103 (lxc)
INFO: CT Name: Pak
INFO: Total bytes written: 101260953600 (95GiB, 68MiB/s)
INFO: archive file size: 80.56GB
INFO: Finished Backup of VM 103 (00:24:01)

INFO: Starting Backup of VM 116 (lxc)
INFO: CT Name: osce
INFO: tar: /mnt/pve/synology/dump/vzdump-lxc-116-2026_08_23-21_24_03.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
ERROR: Backup of VM 116 failed ... exit code 2

INFO: Backup job finished with errors
TASK ERROR: job errors

Polanya jelas: CT 100 dan 116 gagal, CT 103 sukses — di node yang sama, ke storage yang sama, dalam satu job yang sama.

---

Petunjuk Pertama: lxc-usernsexec

Perhatikan perintah yang gagal:

lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - ...

lxc-usernsexec hanya dipakai untuk container unprivileged. Artinya proses tar tidak berjalan sebagai root asli, melainkan sebagai UID 100000 di host.

Konfirmasi dengan:

grep -H unprivileged /etc/pve/lxc/*.conf

/etc/pve/lxc/100.conf:unprivileged: 1
/etc/pve/lxc/101.conf:unprivileged: 1
/etc/pve/lxc/104.conf:unprivileged: 1
/etc/pve/lxc/105.conf:unprivileged: 1
/etc/pve/lxc/108.conf:unprivileged: 1
/etc/pve/lxc/113.conf:unprivileged: 1
/etc/pve/lxc/114.conf:unprivileged: 1
/etc/pve/lxc/116.conf:unprivileged: 1

CT 103 tidak ada di daftar — berarti privileged. Hipotesis terbentuk: masalahnya spesifik pada container unprivileged.

---

Memahami Privileged vs Unprivileged Container

Konsepnya: pergeseran UID

Di Linux, izin file ditentukan oleh angka — UID (User ID) dan GID (Group ID). Root selalu UID 0. Perbedaan mendasar antara dua jenis container ini adalah apakah angka tersebut digeser saat keluar dari container.

Privileged — tidak ada pergeseran sama sekali:

Di dalam CT          Di host
UID 0    (root)  →   UID 0    (root asli)
UID 33   (www-data) → UID 33
UID 1000 (user)  →   UID 1000

Root di dalam container benar-benar root di host. Kalau ada celah keamanan yang membuat proses lolos dari isolasi container, dia langsung memegang kendali penuh atas hypervisor.

Unprivileged — semua UID digeser 100000:

Di dalam CT          Di host
UID 0    (root)  →   UID 100000
UID 33   (www-data) → UID 100033
UID 1000 (user)  →   UID 101000
UID 65535        →   UID 165535

Root di dalam container hanyalah user biasa bernomor 100000 di mata host — tanpa hak istimewa apa pun. Meski proses berhasil lolos dari container, dia tidak bisa berbuat banyak. Ini yang disebut user namespace mapping.

Pemetaan ini terlihat di config container:

bash

cat /etc/pve/lxc/100.conf

unprivileged: 1

Dan definisi rentangnya ada di:

bash

cat /etc/subuid
cat /etc/subgid

root:100000:65536

Artinya: mulai dari UID 100000, sebanyak 65536 UID, dialokasikan untuk container.

Perbandingan praktis

Aspek	Privileged	Unprivileged
Root CT di host	UID 0 (root asli)	UID 100000
Rentang UID	Tidak digeser	100000–165535
Keamanan	Lemah — lolos container = root host	Kuat — lolos container = user biasa
Status di Proxmox	Legacy	Default sejak PVE 4
tar saat backup	Jalan sebagai root asli	Jalan lewat lxc-usernsexec sebagai UID 100000
Mount NFS/CIFS dari dalam CT	Bisa	Perlu features: mount=nfs
Docker di dalam CT	Relatif mudah	Perlu features: nesting=1,keyctl=1
Akses /dev khusus, FUSE	Bisa	Umumnya tidak bisa
Bind mount folder host	Izin mengikuti host	Perlu penyesuaian UID

Kenapa ini penting saat backup

Saat membuat backup, vzdump wajib mempertahankan kepemilikan file asli agar container bisa di-restore dengan benar. Untuk container unprivileged, dia menjalankan tar di dalam user namespace supaya UID yang tercatat di arsip sesuai dengan yang ada di dalam container:

lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - ...

Konsekuensinya: proses tar itu berjalan sebagai UID 100000, bukan root. Dan di sinilah masalahnya muncul — UID 100000 harus dikenali dan diizinkan menulis oleh storage tujuan. Kalau NAS tidak mengenal angka itu, backup gagal, sekalipun root bisa menulis ke folder yang sama tanpa masalah.

Container privileged tidak melewati lxc-usernsexec sama sekali, jadi tar-nya berjalan sebagai root asli — dan root hampir selalu diterima NAS. Itulah kenapa CT 103 tetap lolos.

Cara mengubah privileged ke unprivileged

Tidak ada tombol konversi langsung. Caranya lewat backup lalu restore dengan flag khusus — Proxmox akan otomatis menggeser semua UID/GID di dalamnya:

bash

pct shutdown 102
vzdump 102 --storage truenas --mode stop --compress zstd
pct restore 202 /mnt/pve/truenas/dump/vzdump-lxc-102-XXXX.tar.zst \
  --unprivileged 1 \
  --storage local-lvm
pct start 202

Gunakan ID baru (misal 202), jangan menimpa yang lama, supaya container asli tetap ada sebagai cadangan. Setelah semua layanan terbukti normal, baru hapus yang lama dengan pct destroy 102.

Yang perlu dicek setelah konversi: mount jaringan dari dalam container, Docker, FUSE, dan file dengan UID di atas 65535 — semuanya bisa bermasalah karena root di dalam container tidak lagi punya hak istimewa.

---

Isolasi Masalah

Tes 1 — Ganti storage, container sama

bash

vzdump 100 --storage truenas --mode snapshot --compress zstd

INFO: Total bytes written: 1880135680 (1.8GiB, 64MiB/s)
INFO: archive file size: 391MB
INFO: Finished Backup of VM 100 (00:00:33)
TASK OK

Berhasil. Matriksnya jadi:

	CT 100 (unprivileged)	CT 103 (privileged)
synology	❌ gagal	✅ berhasil
truenas	✅ berhasil	—

Container bukan masalahnya. Proxmox bukan masalahnya. Yang berbeda hanya storage tujuan.

Tes 2 — Cek squash NFS

bash

touch /mnt/pve/synology/dump/tes.txt
ls -l /mnt/pve/synology/dump/tes.txt
touch /mnt/pve/truenas/dump/tes.txt
ls -l /mnt/pve/truenas/dump/tes.txt

-rwxrwxrwx 1 root root 0 Aug 24 09:43 /mnt/pve/synology/dump/tes.txt
-rw-r--r-- 1 root root 0 Aug 24 09:43 /mnt/pve/truenas/dump/tes.txt

Root tidak di-squash (bukan jadi nobody), jadi root squash bukan penyebabnya. Tapi muncul petunjuk baru: mode file di Synology dipaksa 777, sementara TrueNAS normal 644. Ini ciri khas share dengan Windows ACL aktif — bit POSIX yang tampil hanya kosmetik.

Tes 3 — Reproduksi kondisi tar yang sebenarnya

Ini tes yang menentukan. vzdump membuat direktori .tmp, mengubah kepemilikannya ke 100000, baru tar menulis ke sana:

bash

mkdir -p /mnt/pve/synology/dump/tesdir
chown 100000:100000 /mnt/pve/synology/dump/tesdir
ls -ldn /mnt/pve/synology/dump/tesdir
lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- touch /mnt/pve/synology/dump/tesdir/x

drwxrwxrwx 1 100000 100000 0 Aug 24 09:45 /mnt/pve/synology/dump/tesdir
touch: cannot touch '/mnt/pve/synology/dump/tesdir/x': Permission denied

Pembanding di TrueNAS:

drwxr-xr-x 2 100000 100000 2 Aug 24 09:45 /mnt/pve/truenas/dump/tesdir
(tidak ada error)

Pemilik sudah UID 100000, mode 777, tapi tetap ditolak. Secara POSIX ini mustahil — pasti ada lapisan izin lain yang menimpa. Perhatikan juga link count direktori Synology tertulis 1, padahal direktori normal minimal 2. Keduanya menunjuk ke satu hal: Windows ACL Synology yang menegakkan izin sebenarnya, dan ACL itu hanya mengenal user terdaftar di DSM. UID 100000 tidak ada di sana.

---

Menemukan Kapan Masalah Dimulai

bash

ls -la /mnt/pve/synology/dump/ | head -20

-rwxrwxrwx 1   1026 users    410809644 Aug  1 21:00 vzdump-lxc-100-2026_08_01-21_00_02.tar.zst
-rwxrwxrwx 1   1026 users    410864047 Aug  2 21:00 vzdump-lxc-100-2026_08_02-21_00_02.tar.zst
-rwxrwxrwx 1   1026 users   3591211752 Aug 13 13:41 vzdump-lxc-100-2026_08_13-13_41_26.tar.zst
-rw-r--r-- 1 root   root          1509 Aug 19 21:00 vzdump-lxc-100-2026_08_19-21_00_00.log
-rw-r--r-- 1 root   root          1509 Aug 20 21:00 vzdump-lxc-100-2026_08_20-21_00_02.log
-rw-r--r-- 1 root   root          1509 Aug 21 21:00 vzdump-lxc-100-2026_08_21-21_00_00.log

Ini bukti kuncinya:

• Sampai 13 Agustus — file dimiliki UID 1026 grup users (akun DSM), dan arsip .tar.zst ada. Backup berhasil.
• Sejak 19 Agustus — file dimiliki root:root, dan yang tersisa hanya .log tanpa arsip. Backup gagal.

Kepemilikan UID 1026 artinya dulu semua UID yang masuk dipetakan ke akun admin DSM. Kepemilikan root:root artinya sekarang UID diteruskan apa adanya. Setting squash NFS di Synology berubah antara 13 dan 19 Agustus.

Konfirmasi di DSM (Control Panel → Shared Folder → Edit → NFS Permissions):

---

Akar Masalah

Rangkaian sebabnya:

1. Share Synology mengaktifkan Windows ACL, sehingga izin ditegakkan oleh ACL DSM, bukan bit POSIX.
2. ACL DSM hanya mengenal user yang terdaftar di sana. UID 100000 tidak terdaftar.
3. Squash NFS diubah ke No mapping, sehingga UID 100000 diteruskan apa adanya ke NAS.
4. tar untuk container unprivileged berjalan sebagai UID 100000 → ditolak.
5. Container privileged tetap lolos karena tar-nya berjalan sebagai root, yang dipetakan ke administrator DSM.

Ironisnya, squash yang selama ini dianggap "kurang aman" justru yang membuat backup unprivileged berfungsi berbulan-bulan.

---

Solusi

Opsi A — Kembalikan Squash di DSM (yang saya pakai)

Di DSM: Control Panel → Shared Folder → pilih share → Edit → NFS Permissions → pilih rule → Edit

Ubah Squash menjadi:

Map all users to admin

Simpan, lalu remount di Proxmox:

bash

pvesm set synology --disable 1
sleep 3
pvesm set synology --disable 0

Verifikasi:

bash

mkdir -p /mnt/pve/synology/dump/tesdir
chown 100000:100000 /mnt/pve/synology/dump/tesdir
lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- touch /mnt/pve/synology/dump/tesdir/x
rm -rf /mnt/pve/synology/dump/tesdir

Tes backup sungguhan:

vzdump 100 --storage synology --mode snapshot --compress zstd

INFO: creating vzdump archive '/mnt/pve/synology/dump/vzdump-lxc-100-2026_08_26-13_01_22.tar.zst'
INFO: Total bytes written: 1880176640 (1.8GiB, 64MiB/s)
INFO: archive file size: 391MB
INFO: Finished Backup of VM 100 (00:00:33)
INFO: Backup job finished successfully
TASK OK

Selesai.

Opsi B — Pindahkan tmpdir ke Disk Lokal

Kalau tidak ingin mengendurkan setting NAS, masalah bisa diselesaikan dari sisi Proxmox. Direktori .tmp yang bermasalah hanya berisi pct.conf dan pct.fw — beberapa KB saja. Arsip utamanya tetap ditulis root ke NAS.

Sekali jalan:

bash

vzdump 100 --storage synology --mode snapshot --compress zstd --tmpdir /var/tmp

Permanen (berlaku juga untuk job terjadwal dan tombol GUI):

bash

echo "tmpdir: /var/tmp" >> /etc/vzdump.conf
cat /etc/vzdump.conf

Pastikan barisnya tidak diawali #. Cek juga /var/tmp punya ruang cukup dan bukan tmpfs:

bash

df -h /var/tmp
findmnt -T /var/tmp

---

Memahami Permission di NAS

Ada tiga lapisan yang menentukan apakah sebuah proses boleh menulis ke share NFS. Ketiganya harus lolos. Kegagalan di kasus ini terjadi di lapisan ketiga, sementara dua lapisan pertama sudah benar — itulah kenapa awalnya membingungkan.

Lapisan 1 — Export rule NFS

Menentukan siapa yang boleh mount. Di Synology diatur per-share:

Client: 192.168.xx.xx | Privilege: Read/Write

Kalau lapisan ini gagal, gejalanya mount: access denied atau storage tidak aktif sama sekali. Di kasus kita lapisan ini lolos — mount berhasil dan root bisa menulis.

Lapisan 2 — Squash (penerjemahan UID)

Menentukan UID client diterjemahkan jadi UID apa di server. Inilah lapisan yang berubah dan memicu masalah.

Pilihan di DSM	Padanan Linux	Perilaku	Efek ke UID 100000
No mapping	no_root_squash	Semua UID diteruskan apa adanya	Tetap 100000 → ditolak ACL
Map root to admin	root_squash	Hanya UID 0 → admin	Tetap 100000 → ditolak
Map root to guest	root_squash (ke guest)	UID 0 → guest	Tetap 100000 → ditolak
Map all users to admin	all_squash	Semua UID → admin (UID 1026)	Jadi 1026 → diterima
Map all users to guest	all_squash (ke guest)	Semua UID → guest	Diterima, hak terbatas

Poin pentingnya: yang lazim dianggap "paling aman" adalah Map root to admin (setara root_squash). Tapi opsi itu tidak menolong di kasus ini, karena yang bermasalah bukan root — melainkan UID 100000. Hanya Map all users to admin yang memetakan semua UID, termasuk 100000, ke akun yang dikenal DSM.

Cara membaca squash tanpa membuka DSM — cukup lihat pemilik file yang baru dibuat:

bash

touch /mnt/pve/synology/dump/tes.txt && ls -l /mnt/pve/synology/dump/tes.txt

Hasil	Artinya
root root	No mapping
nobody nogroup (atau UID 65534)	Root di-squash ke guest
UID akun DSM, misal 1026 users	Map all users to admin

Lapisan 3 — ACL di sisi NAS

Ini lapisan yang paling sering luput, karena tidak terlihat dari sisi client. Setelah UID diterjemahkan, server masih memeriksa izin file sistem lokalnya sendiri — dan di sinilah dua NAS berperilaku sangat berbeda.

Synology dengan Windows ACL aktif:

Izin sebenarnya ditegakkan oleh ACL bergaya Windows yang hanya mengenal user dan grup terdaftar di DSM. Bit permission POSIX yang tampil di client cuma kosmetik — Synology memaksanya jadi 777 agar aplikasi tidak protes, tapi angka itu tidak mencerminkan apa pun.

Inilah kenapa hasil tes tampak mustahil:

drwxrwxrwx 1 100000 100000 0 Aug 24 09:45 /mnt/pve/synology/dump/tesdir
touch: cannot touch '.../x': Permission denied

Pemilik sudah UID 100000, mode 777, tapi tetap ditolak — karena ACL DSM tidak punya entri untuk UID 100000, dan ACL-lah yang memutuskan.

Dua ciri share ber-ACL yang bisa dikenali dari client:

• Mode file selalu 777/rwxrwxrwx, tidak peduli umask
• Link count direktori bernilai 1, padahal direktori normal minimal 2

TrueNAS dengan ZFS ACL POSIX:

Berperilaku seperti Linux biasa. chown dan chmod dihormati sepenuhnya, UID 100000 diperlakukan sebagai user biasa:

drwxr-xr-x 2 100000 100000 2 Aug 24 09:45 /mnt/pve/truenas/dump/tesdir
(tulis berhasil)

Perbandingan singkat

	Synology (Windows ACL)	TrueNAS (ZFS, POSIX/passthrough)
Penegak izin	ACL DSM	Bit POSIX + ACL
Kenal UID arbitrer	Tidak — harus terdaftar di DSM	Ya
chown dari client	Terlihat berubah, tapi diabaikan	Dihormati
Mode file baru	Dipaksa 777	Normal (644/755)
Cocok untuk target vzdump	Perlu penyesuaian squash	Langsung jalan

Praktik yang disarankan

Kalau membuat share baru di Synology khusus untuk target vzdump, jangan centang "Enable Windows ACL" saat pembuatan. Share tanpa ACL berperilaku seperti NFS pada umumnya dan menerima UID 100000 tanpa masalah.

Menonaktifkan ACL pada share yang sudah ada memang bisa lewat Shared Folder → Edit → Advanced, tapi berisiko me-reset izin seluruh isi folder — kurang nyaman kalau share itu juga dipakai layanan lain. Membuat share baru lebih aman.

Catatan keamanan: Map all users to admin memberi akses penuh ke share bagi siapa pun yang bisa me-mount-nya. Batasi rule ke IP node saja, bukan seluruh subnet, dan hanya pakai di jaringan internal tepercaya. Kalau kebijakan keamanan tidak mengizinkan, Opsi B (tmpdir) adalah jalan keluar yang tidak menyentuh setting NAS sama sekali.

 

---

Pelajaran yang Diambil

Kegagalan sebagian lebih informatif daripada kegagalan total. Fakta bahwa satu container tetap sukses langsung mempersempit ruang pencarian — variabelnya tinggal privileged vs unprivileged.

Kepemilikan file lama adalah catatan sejarah. Perubahan pemilik dari 1026 users menjadi root root menunjukkan dengan tepat kapan konfigurasi berubah, bahkan tanpa akses ke log DSM.

Uji reproduksi harus setia pada kondisi asli. Tes pertama saya (mkdir lalu tulis sebagai UID 100000) gagal di kedua NAS dan sempat menyesatkan — karena mkdir membuat direktori 755 milik root, yang memang tidak bisa ditulis UID 100000 di mana pun. Baru setelah ditambahkan chown 100000:100000 — persis seperti yang dilakukan vzdump — perbedaannya terlihat.

Notifikasi yang tidak dibaca sama dengan tidak ada notifikasi. Job ini mengirim laporan ke mail-to-root dan gagal selama berhari-hari tanpa disadari. Arahkan ke alamat yang benar-benar dipantau lewat Datacenter → Notifications.

---

Ringkasan Cepat

Gejala: tar: ...tmp: Cannot open: Permission denied, exit code 2. Hanya container unprivileged yang gagal.

Penyebab: Squash NFS di Synology diubah ke No mapping, sementara share memakai Windows ACL yang tidak mengenal UID 100000.

Solusi: Ubah Squash ke Map all users to admin dan remount storage — atau tambahkan tmpdir: /var/tmp di /etc/vzdump.conf.

Subscribe to receive free email updates: