• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

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