This episode manages multi-tenant access: creating per-tenant users, installing per-datastore ACLs with the Backup, Read, or Write roles, and creating API tokens with limited permissions for integration. You will also secure remote access — the web UI only through valid HTTPS, and SSH not opened without a real need.

Backup already extended to hosts and containers in episode 11 — now there is an operational question: who is allowed to access what. In real environments, PBS is not used by one person: infrastructure teams, application teams, even different tenants share the same server. Episode 12 builds ACL, user, and remote access that makes PBS both secure and easy to manage.
Imagine PBS like a leased office building: every tenant has its own floor (datastore), an access card (user/token) that only opens its floor, and different permission levels — some can store and retrieve, some can only view. The main building door (HTTPS) is guarded, and the back door (SSH) is not opened without a reason.
PBS separates who (user) from what is allowed (ACL/role) and where (path). ACLs are attached to a specific path (e.g. /datastores/store1) with a specific role:
The user-per-tenant pattern: one user per team/tenant, with ACLs restricted to its own datastore.
proxmox-backup-manager user create finance@pbs --password 'fin-strong-pass'proxmox-backup-manager acl update \
/datastores/finance finance@pbs DatastoreBackupfinance@pbs can now backup/restore on /datastores/finance, but cannot see other datastores. With namespaces (episode 11), granularity can be even finer: /datastores/store1/finance separates tenants within a single physical datastore.
Note
ACL roles do not automatically inherit from each other: DatastoreReader cannot upgrade itself. Design minimal roles — give DatastoreBackup to operational teams, DatastoreReader to auditors, and keep DatastoreAdmin only for infrastructure admins.
User passwords are for humans; API tokens are identities for machines (PVE, sync jobs, scripts). Tokens inherit their user's ACL permissions and can be revoked at any time without changing the user password:
proxmox-backup-manager api-token create finance@pbs pve-backup --privsep--privsep (privilege separation) limits the token to only the operations needed. Tokens are shown only once — save it immediately. In PVE, this token is used when registering PBS as storage (episode 4) in place of the password:
pvesm add pbs pbs1 --server 10.0.1.10 --datastore finance \
--username finance@pbs --password 'pbs-token=...' --fingerprint AA:BB:...Warning
Do not use the root@pam user with a full-access token for all integrations. One token per consumer (PVE cluster, sync job, CI script) makes audit and revoke easy — if one consumer is compromised, you revoke its token without touching the others.
The PBS web UI is HTTPS-native on port 8007 with a configurable certificate. For production:
This rule is often ignored: PBS SSH does not need to be open to the world. Daily PBS administration goes through the web UI/API. If SSH is truly needed:
AllowUsers in sshd_config).PermitRootLogin prohibit-password
PasswordAuthentication no
AllowUsers ops@10.0.0.0/24After changing the configuration, restart sshd and test the connection — do not close an active session before confirming new connections work.
Key takeaways:
DatastoreBackup, DatastoreReader, DatastoreAdmin.--privsep) are identities for machines; one token per consumer, easy to revoke.pvesm add pbs instead of the user password.In the next episode, episode 13, we will harden the network: network isolation & firewall — separating the storage VLAN, limiting port 8007 access to PVE nodes only with UFW, and managing TLS certificates (Let's Encrypt/PKI) complete with fingerprint verification on the client side. Backups are the most valuable data in your network!