When you use the SAS Viya Backup and Restore functionality to run a backup, the CAS backup might fail with either an Insufficient authorization error or a java.nio.file.AccessDeniedException error. These types of failures can occur when permissions and group membership requirements are not set correctly. As a result, the CAS backup action might fail or failures might occur in copying the CAS backup from the local-vault location to the shared vault (set by the sharedVault property).
When you create a backup in this way, the backup for each source type (CAS, PostgreSQL, RabbitMQ, and Consul) is first copied to the local vault (/opt/sas/viya/config/backup). Then, the backup is copied to your shared-vault location. A distinction between the backup of the other source types and the backup of the CAS permstore directory is who manages the backup processes. For source types other than the CAS type, the sas user manages the backup processes. For the CAS permstore directory, the cas user account manages the backup processes.
When the backup runs, first the sas user creates directories with 770 permissions up to this level: /opt/sas/viya/config/backup/backup-ID/__default__/. Here is an example of the permissions that are assigned to __default__ directory:
Next, the /opt/sas/viya/config/backup/backup-ID/__default__/ path is supplied to the CAS backup action. Then, as the cas user, the CAS backup action creates a directory named cas-shared-default and subdirectories. The user ownership is cas and the group ownership is the cas user's primary group. Here is an example of user and group permissions that are assigned to the cas-shared-default directory and to subdirectories:
Failures can occur when the CAS backup action creates /opt/sas/viya/config/backup/backup-ID/__default__/cas-shared-default and subdirectories. These failures occur when the cas user is not in the sas group. This issue occurs because /opt/sas/viya/config/backup/backup-ID/__default__ is owned by the sas group, with 770 permissions set.
The following example errors illustrate those that are displayed in the cas_yyyy-mm-dd_host-name_pid.log CAS logs, which reside in the /opt/sas/viya/config/var/log/cas/default directory. These CAS logs are on the CAS controller in a single-tenant environment.
The following errors are examples of those that are displayed in the cas_yyyy-mm-dd_host-name_pid.log CAS logs that reside in /opt/sas/viya/config/var/log/cas/default. These CAS logs are on the CAS controller in a multi-tenant environment for the provider tenant.
In addition, when the primary group of the cas user is not the sas group, failures can occur when /opt/sas/viya/config/backup/backup-ID/__default__/cas-shared-default is copied to your shared-vault location (set by the sharedVault property). These failures occur because when CAS backup action creates the cas-shared-default directory, group ownership is determined by the primary group that you assigned to the cas user account. When the primary group of the cas user is not the sas group, the sas user does not have permission to copy cas-shared-default from your local vault to your shared vault. In multi-tenancy environments, this issue can occur also when a CAS controller runs with a user account that is not part of sas group. The following examples show various errors that can appear in sas-deploymentBackup logs when these issues occur. The logs that are named sas-deploymentBackup_yyyy-mm-dd_hh-mm-ss.log reside in /opt/sas/viya/config/var/log/deploymentBackup/default.
Example Error 1:
Example Error 2:
Example Error 3:
Example Error 4 (multi-tenant environment for a tenant named cas-tenant1-default):
To resolve these errors, on both the CAS controller (and backup CAS controller, if it exists) ensure that the cas user is in the sas group and ensure that the primary group for the cas user is the sas group. Alternatively, if a CAS controller is running with a user account that is not part of the sas group (such as with multi-tenancy environments), perform the steps to set appropriate permissions using access control lists (ACLs) on the local vault for a successful backup-and-restore process. The steps are available in the section Backup and Restore: Initial Tasks in SAS Viya 3.5 Administration.
Note: If you report a problem to SAS Technical Support, always provide the following logs that are from the same time period as the problem:
After you perform the steps, you might need to restart sas-viya-deploymentBackup-default, sas-viya-backup-agent-default (on CAS controller), and sas-viya-cascontroller-default microservices. Restart these services by submitting the commands below: