• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

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