[SOLVED] Permission failure with push sync feature

McTwist

New Member
Jun 14, 2023
9
3
3
Sweden
While trying the new "push sync" feature, I found out that it always fails with logs telling me about insufficient permission for the action.

Code:
Encountered errors: Pushing to remote namespace not allowed: missing permissions 'Remote.DatastoreBackup' on '[...]'

The sync goes from a namespace into another namespace. I have given Admin role to both the root namespace and the specific namespace. If I limit the permission to 'RemoteSyncPushOperator', it will only give me the following error:

Code:
Encountered error: Creating remote namespace not allowed: missing permissions 'Remote.DatastoreModify' on '[...]'

And fixing that will only revert to the previous error.

I have searched both on the forum and everywhere else for a solution, while also tinkering with different configs, but found nothing that works. Given this feature is only a month old, I do not expect many users going to use it, and therefore not many issues will surface. Especially when tutorials/documentation recommend "pull sync".

I will escalate this as a bug if I find no solution for it or any response at all.
 
Hi,
Encountered errors: Pushing to remote namespace not allowed: missing permissions 'Remote.DatastoreBackup' on '[...]'
The user on the source side needs the permissions to create backups on the remote (push target). The Remote.SyncPushOperator is allowed to read the remote and push snapshots, but not to create/delete namespaces or prune contents. Remote.DatastorePowerUser also has the permissions to prune, but not the permissons to create or remove namespaces. You will have to use Remote.DatastoreAdmin for the user to be allowed to create and remove namespaces on the remote.

See also https://pbs.proxmox.com/docs/managing-remotes.html#sync-direction-push
 
  • Like
Reactions: Johannes S
As I have already said, the user(s) are Admin(s) on both sides, still it complains. I would not normally post anything here unless I have exhausted all my options and deducted that something is not according to the documentation or makes no sense logically.
 
Last edited:
As I have already said, the user(s) are Admin(s) on both sides, still it complains. I would not normally post anything here unless I have exhausted all my options and deducted that something is not according to the documentation or makes no sense logically.
Please share the contents of /etc/proxmox-backup/sync.cfg and /etc/proxmox-backup/acl.cfg. Note that it is not enough for the sync user on the source side to have Admin permissions on the source datastore, it is further required to have permissions configured for the remote on the sync source.
For example, the local user for the sync job would need something along the line of the ACLs below on the source PBS instance:
Code:
acl:1:/datastore/source-datastore:pushuser@pbs:DatastoreAdmin
acl:1:/remote/remote-name/target-datastore:pushuser@pbs:RemoteDatastoreAdmin

In addition, the user configured and used to connect to the remote requires the permission to access the datastore configured on the remote instance.
 
Source PBS: retainer
Code:
sync: s-6238b631-910c
        ns public
        owner mctwist@pbs
        remote courage
        remote-ns public
        remote-store saroma
        remove-vanished false
        store notoro
        sync-direction push
Code:
acl:1:/datastore/notoro:mctwist@pbs:Admin

Remote PBS: courage
Code:
acl:1:/datastore/saroma:mctwist@pbs:Admin

No-edit: After checking your acl, I saw that it has a /remote in it, I therefore checked in my Access Control and saw that it had /remote (though, not /remote/courage/saroma). After adding /remote, I got it working.

While this solves my issue, and I do understand the reasoning behind having it built like this, it is still non-intuitive for most users, and even if the documentation mentions /remote, it is not understandable if it is going to be set on the source or the remote. Thank you for the help, and I hope there could be an update in the future that makes it a bit easier to understand.
 
  • Like
Reactions: ITT
I also stumbled over this issue and it took me about an hour to figure it out

Like others in this thread already pointed out it is important to have the permission for the remote datastore on the remote pbs set on the source pbs. ❗
So it is not sufficient to have the permissions set on the remote pbs only.

The best way to figure this out is to check the content of /etc/proxmox-backup/acl.cfg on both machines and make sure there are at least two lines in there on the source (first for the source datastore, second for the remote one) like @Chris pointed out. You can also use the GUI at Configuration => Access Control => Permissions for that.

So an example configuration on my hosts is as follows:

Source PBS (push source)

Hostname: anna
/datastore/PBSstorage is source datastore for push job
mylocaluser@pbs is backup user on source pbs

Content of /etc/proxmox-backup/acl.cfg:
Code:
acl:1:/datastore/PBSstorage:mylocaluser@pbs:DatastoreAdmin
acl:1:/remote/berta/local-storage/anna:mylocaluser@pbs:RemoteDatastoreAdmin

Content of /etc/proxmox-backup/sync.cfg:
Code:
sync: s-5c608db1-1234
    comment Send the last three snapshots to remote PBS
    encrypted-only false
    ns
    owner mylocaluser@pbs
    remote berta
    remote-ns anna
    remote-store local-storage
    remove-vanished false
    schedule fri 18:15
    store PBSstorage
    sync-direction push
    transfer-last 3
    verified-only true

Remote PBS (push target)​

Hostname: berta
/datastore/local-storage is remote datastore for push job
I added the following namespace for the source PBS to push onto: /datastore/local-storage/anna
remotebckpuser@pbs is backup user on remote pbs (this is the user being used to add the remote pbs to the source pbs in Configuration => Remotes)

Content of /etc/proxmox-backup/acl.cfg:
Code:
acl:1:/datastore/local-storage/anna:remotebckpuser@pbs:DatastoreBackup
acl:1:/remote/berta:remotebckpuser@pbs:RemoteAudit
acl:1:/remote/berta/local-storage/anna:remotebckpuser@pbs:RemoteDatastoreAdmin

Hope this saves others some time on this "weird" understanding of having to set permissions for a target on the source too