• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion
  • Inviting everyone to the UX test of a new security feature in the WP Toolkit
    For WordPress site owners, threats posed by hackers are ever-present. Because of this, we are developing a new security feature for the WP Toolkit. If the topic of WordPress website security is relevant to you, we would be grateful if you could share your experience and help us test the usability of this feature. We invite you to join us for a 1-hour online session via Google Meet. Select a convenient meeting time with our friendly UX staff here.

Resolved Backup Manager warning

pinncomp

New Pleskian
We are seeing backup manager warning just like those exhibited in this thread here: Resolved - Backup problem after upgrade to Obsidian 18.0.40

The backup Sept 7, 2023 04:14 PM was created and can be restored, although some minor issues occurred.
Warning: Subscription "domain.com"
Unable to back up files from /sitedata/var/www/vhosts/domain owned by system user. Error: Failed to create archive: backup_user-data_2309071614.tzst 25 Repository error: Unable to pack /sitedata/var/www/vhosts/domain.com /usr/lib/plesk-9.0/sw-tar: /sitedata/backupcache/pmm-ru-ca-includes-jegIBK: Cannot stat: Permission denied /usr/lib/plesk-9.0/sw-tar: Error is not recoverable: exiting now

Appears to be a log for each hosted domain

However, we are running Plesk Obsidian Web Host Edition 18.0.54 Update #4 on Ubuntu 20.04 (Azure image plan)
Our vhosts were redirected from day one to a separate disk from root, and permissions appear correct. No other issues we are aware of other than the soft warning.

Appreicaite any insight. Curious if a component or setting didn't take on a previous update which fixed this issue.
 
I'd guess that the /sitedata path has something to do with it. Have you checked if the DUMP_D and DUMP_TMP_D paths defined in /etc/psa/psa.conf exist and have write permissions (for DUMP_D owner and group must be psaadm, permissions must be at least 0750; for DUMP_TMP_D owner and group should be root with permissions 1777 (your ordinary temp partition))?
 
Peter, thanks for this. It appears that I had swapped the permissions and ownership as you described between these two settings. Changing them as you described has corrected the issue. I appreciate it very much!
 
Back
Top