PBS: New instance add existing datastore - errors

dllfpp

New Member
Apr 30, 2025
6
1
3
Hello, I've just setup a new PVE with PBS standalone.
I'm going through some DR tests before switching everything to production.

Current setup below.
Hardware:
- 2 PVE hosts
- 1 PBS host
- 1 QNAP with NFS share
Configuration:
- 2 PVE hosts clustered together
- QNAP NFS share is limited as source from PBS, read+write, no_root_squash
- PBS mounts NSF share from QNAP as Datastore
- PVE Datacenter mounts PBS Datastore

What's wrong:
I successfully imported PBS datastore over the two PVEs. Configured daily backup of one VM, works flawlessly.
I am simulating an hardware failure on PBS: I have created a new PBS and when I try to add the existing datastore from the QNAP (after configuring the correct mountpoint in /etc/fstab) I get the following error:
Code:
unable to open existing chunk store path "/mnt/qnap_backup" - permissions or owner not correct
I've gone through ACL removal, ownership re-apply...tested a lot of suggested solutions I found here and there but none of them work.
Also removing and re-adding the same datastore to the initial PBS gives the same error.

How can I re-add an existing datastore if my PBS/PVE get corrupted and need bare-metal reinstallation?

Thanks for helping.
 
Last edited:
This is certainly a permission problem. U have to control the uids. My suggestion to you is: when the qnap offer virtualization then install pbs as VM on qnap direct.
 
  • Like
Reactions: Johannes S
This is certainly a permission problem. U have to control the uids. My suggestion to you is: when the qnap offer virtualization then install pbs as VM on qnap direct.
It does but what is the actual root cause of this? What can I check/do in order to fix this? I would prefer to have dedicated (and separated) hardware for the three things (PVE/PBS/Backup repository).
 
Pbs with NFS is slow (see forum posts), more iops with iscsi but as VM direct on qnap you will get the best performance especially for consistency check and garbage collection
 
Last edited:
  • Like
Reactions: Johannes S
Ok, how can a VM inside the QNAP access a QNAP's volume (or share, or similar)?
Wouldn't it be still considered as a separate entity from the device, so that PBS needs to mount whatever external datastore via network??
Thanks for clarifying this, please.
 
Ok done this but same thing is happening. Even if I create a new VM and attach the old .img disk to the new one, although I'm able to mount the volume to a /mnt/folder/structure, I get the same authorization/permission problem.
Any thoughts?

EDIT:
When I attach the existing disk and mount it via
Code:
mount /dev/vdb1 /mnt/datastore/PBS_QNAP01
(it's ext4), via MC I can surf the folder and see the content, but adding it via PBS GUI or uploading the old datastore.cfg file, it fails due to incorrect permissions.
 
Last edited:
Fixed by
Code:
chown backup:backup -R /mnt/datastore/PBS_QNAP01
chmod -R 700 /mnt/datastore/PBS_QNAP01

After this I could re-add the existing disk with data and previous backups.
Thanks for the support @floh8!!
 
  • Like
Reactions: Johannes S
I also had the problem, to add an existing datastore from my former PBS under the previous OS-release to a new installed PBS on different hardware (less energy consuming Dell Wyse 5070 with external HDD) under the latest PBS 4.0.14 OS.
I tried a lot and got the message about wrong or missing permissions again and again even though i followed the hints in different posts in different threads about this issue.
In one i found Hannes Laimers link https://git.proxmox.com/?p=proxmox-...c312d5848879be9f3a49dc031ada49ac03654526#l599 to the code that checks for correct permissions in the program. Since i'm not a coder or Linux-guru it wasn't too easy for me, to read the necessary information out of the code, but i finally got it.

I finally could set the neccessary permissions, when i found out, that it's necessary to set different permissions for the .chunks-directory than for the included directories and files, and how to do that. I couldn't do it with only chmod (maybe too dumb), but i found a workaround:

1.
Code:
chmod -R 777 /mnt/datastore/mydatastore
2.
Code:
chmod -R 750 /mnt/datastore/mydatastore/.chunks
3.
Code:
find /mnt/datastore/mydatastore -type d -exec chmod 755 {} +
4.
Code:
find /mnt/datastore/mydatastore/.chunks -type d -exec chmod 750 {} +
5.
Code:
chmod -R 644 /mnt/datastore/mydatastore/.lock
5.
Code:
chmod -R 644 /mnt/datastore/mydatastore/.gc-status