Remote Sync Error When Selecting Source Datastore

E

ericz

New Member
Mar 21, 2024
12
1
3
I'm trying to add a sync job to a remote PBS server. I've already added the remote PBS system to the Remotes section of the local PBS. In the Add: Sync Job dialog I can choose the Source Remote, but, when I try to choose the Source Datastore I get "Internal Server Error (500) failed to scan remote 'pbs-wa' - remote connection to '192.168.8.9' failed - permission check failed".

Even more strange to me is that sometimes I see the remote datastore's name (primary) for a second, if I select it I get "[object Object]".

In an attempt to bypass all permissions issues I added a, /datastore/primary, syncUser@pbs, Admin, entry on the remote server. This entry is in addition to, /datastore/primary, syncUser@pbs, DatastoreReader.

I'm running PBS 3.2-2 on the local system and PBS 3.2-3 on the remote system.
 
ericz said:
I'm trying to add a sync job to a remote PBS server. I've already added the remote PBS system to the Remotes section of the local PBS. In the Add: Sync Job dialog I can choose the Source Remote, but, when I try to choose the Source Datastore I get "Internal Server Error (500) failed to scan remote 'pbs-wa' - remote connection to '192.168.8.9' failed - permission check failed".

Even more strange to me is that sometimes I see the remote datastore's name (primary) for a second, if I select it I get "[object Object]".
In an attempt to bypass all permissions issues I added a, /datastore/primary, syncUser@pbs, Admin, entry on the remote server. This entry is in addition to, /datastore/primary, syncUser@pbs, DatastoreReader.

I'm running PBS 3.2-2 on the local system and PBS 3.2-3 on the remote system.
Click to expand...
Make sure the API credentials you are using for the sync task have the correct permissions. Since you have added syncUser@pbs as an Administrator on the remote server.
 
Thanks for the suggestion @tracyberg. By API credentials I assume you mean the an entry under Access Control / API Token. I wasn't using tokens for my setup, just the username and password.

In an event I created a new user from scratch, gave it admin permissions, setup my sync job, and then changed the permissions to DatastoreReader. This seems to work. It seems like there could be issues in the future though. I just didn't like the idea of leaving the permissions at Admin.
 
You have the right mindset in that you don't want to make Backups as the Admin user/with Admin rights. When the Backup-User has write permissions on your PBE, an intruder on your PVE host can delete your backups.

What you could do is the following:
- Backup-User (e.g. User that the PVE uses to access your PBS): DatastoreBackup permission on your datastore(s)
- Sync-User (e.g. User configured on PBS#1 that PBS#2 uses to access its sync targets): DatastoreBackup and DatastoreReader permission on your datastore(s)
 
Hi @B.Otto our setup is as you described, except I don't give the syncUser the DatastoreBackup role. Maybe that is an issue.

* PVE pushes backups to on-site PBS-WA (backupUser).
* PBS-OR (off-site) syncs backups from PBS-WA (syncUser).
* PBS-WA-offline (air gapped when not actively syncing) syncs backups from PBS-WA (syncUserOffLine).
 
I never see people talking about Namespaces on these posts.
But ... right after you mix VM populations, you run into namespace issues. It happens immediately.
If you aren't managing it, it can completely b0rk your backups.

So you discover this. And you add Namespaces.
And then what happens with your Sync-User account?
Does it have access to the new Namespaces? I think "No."

I wound up having to recreate users and namespaces in the proper order.
Adding the permissions again didn't work.
 
You must log in or register to reply here.
Top Bottom