Applicable to:
- Plesk for Linux
Symptoms
Plesk update or upgrade failed:
PLESK_ERROR: chown: changing ownership of `/var/lib/psa/dumps/mysql.preupgrade.11.5.30-11.5.30.20131211-190722.dump.gz': Operation not permitted
or:
PLESK_ERROR: ... touch: setting times of '/mnt/opendrive/webserver/Backup/mysql.preupgrade.17.5.3-17.5.3.20170921-194900.dump.gz': No such file or directory
ERROR while trying to backup MySQL database
Check the error reason(see log file: /var/log/plesk/install/plesk_17.5.3_installation.log), fix and try again ERROR: An error occurred during performing of installation PREP actions (see log for details). Installation was rolled back.
Warning! Not all packages were installed.
Please check if your system services are operable.
Please resolve this issue and try to install the packages again.
If you cannot resolve the issue on your own, contact product technical support for assistance.
or:
PLESK_ERROR: EMERGENCY: Unable to write in the /backup_custom directory. The upgrade procedure will fail. Check that the folder exists and you have write permissions for it, and repeat upgrading.
Backup location was customized:
# grep -i dump /etc/psa/psa.conf
DUMP_D /backup_custom
DUMP_TMP_D /backup_custom/tmp
It's not possible to create a new file on this location:
# touch /backup_custom/test.txt
touch: setting times of ‘/backup_custom/test.txt’: No such file or directory
Cannot change the backup directory permissions because it is mounted in read-only mode:
# chmod 750 /backup_custom
chmod: changing permissions of /backup_custom: Read-only file system
# mount | grep backup
/dev/sdc1 on /backup_custom type ext4 (ro,relatime,discard,data=ordered,_netdev)
Cause
During the upgrade process Plesk creates databases (psa, horde) dumps. Prior to dumping database, it corrects permissions for files in the backup directory. If backup directory is located on NFS share or external drive, Plesk fails to change permissions there and create a backup.
Resolution
Note: if you don't have root access to Plesk server via SSH, contact your hosting provider regarding the issue
-
Login to the server over SSH
-
Back up
/etc/psa/psa.confconfiguration file# cp /etc/psa/psa.conf{,.orig}
-
Change the backup location directory to a default one:
# grep -n DUMP /etc/psa/psa.conf
DUMP_D /var/lib/psa/dumps
DUMP_TMP_D /tmp - Make sure both directories have the same permissions as:
# ls -ld /var/lib/psa/dumps
drwxr-x--- 6 psaadm psaadm 20480 Sep 22 02:46 /var/lib/psa/dumps
# ls -ld /tmp
drwxrwxrwt 29 root root 20480 Sep 22 03:01 /tmp -
Complete the update or upgrade in Tools&Settings > Updates & Upgrades
-
When upgrade process is finished, revert the changes made in
/etc/psa/psa.conf
Workaround for remote NFS share used as a backup location:
Note: Applying the following workaround will lead to changing user:group to root:root, which should not lead to any drawbacks since NFS treats user root as ordinary one.
1. Log into the NFS server via SSH.
2. Open /etc/exports and set 'no_root_squash' option to the share configuration string. For example:
CONFIG_TEXT: /srv/nfs 203.0.113.2/32(rw,sync,sec=sys,no_root_squash)
3. Apply the configuration settings:
# exportfs -avr
For remote SMB share used as a backup location, contact system administrator to adjust the following ownership/permissions:
# ls -ld /var/lib/psa/dumps
drwxr-x--- 6 psaadm psaadm 20480 Sep 22 02:46 /var/lib/psa/dumps
Comments
8 comments
this is a manual solution, but we need an automated solution.
is not possible to change with an sript before plesk update and after plesk update to change this file?
@Luis Zubeldia
Hello!
I suggest providing your idea on User Voice: https://plesk.uservoice.com/forums/184549-feature-suggestions
The top-ranked suggestions are likely to be included in the next versions of Plesk.
Can't the upgrade/backup script at *least* check to see if the ownership is *already* psaadm:psaadm and not run chown on it if it is? Seems like that's at least a bare min check, no?
We use NFS storage with a bindfs layer to force psaadm:psaadm ownership over all files within, however even in that instance, where ownership is always psaadm, we *still* get an error like: `chown: changing ownership of `/var/lib/psa/dumps/mysql.preupgrade.17.8.11-17.8.11.20190821.dump.gz': Operation not permitted`
Hello @Websavers Inc,
Thank you for your question.
In case if NFS is used, then it is recommended to follow steps under the Workaround for remote NFS share used as a backup location field.
If any issue is still encountered after that, please submit a request to Plesk Technical Support: How to submit a request to Plesk support?
Hey @Daria Gavrilova,
Thanks for the response! I wish we could, but our understanding is that those steps in the workaround must be applied to the *NFS server* not the Plesk server running the NFS client. Is that accurate? We don't have SSH/root access to the NFS server in question, just space allotted on the server, which means we cannot make those changes.
Also, the workaround says to use root:root as the permissions, which would solve this particular problem of Plesk updates not working, however doesn't the *rest* of the dumps folder require psaadm:psaadm ownership for Plesk backups to work successfully? In other words, doesn't this mean that we can *either* configure ownership to work well with updates OR backups but never both at the same time?
Hello @Websavers Inc,
Yes are right, those steps should be applied on the remote NFS server.
I am afraid, there is no solution which can be applied on the NFS client side.To fix the issue with updating Plesk, I suggest configuring default backup locations manually and considering using another remote backup solution:
https://docs.plesk.com/en-US/onyx/customer-guide/78922/
The default configuration is applied in /etc/psa/psa.conf and looks like the following:
# Backups directory
DUMP_D /var/lib/psa/dumps
# Backups temporary directory. DUMP_TMP_D should not be inside of (or equal to) DUMP_D.
DUMP_TMP_D /tmp
As for the questions with backup permissions, when the solution is applied everything should work as expected. Without "no_root_squash" option ownerships look like the following on an NFS server:
CONFIG_TEXT: -rw-r----- 1 nobody system_user backup_dd_conf_1901010000_1901020000.tgz
Thanks @Maxim Krasikov! So the key here is that the mount *needs* to be owned by root and *not* psaadm. It's odd because default permissions for a lot of those dirs are psaadm. Perhaps there should be some consistency to it in that everything *should* be under EITHER psaadm user:group ownership or root within /var/lib/psa/dumps.
Hello @Websavers Inc,
If option "no_root_squash" is used, backups creation, backups restoration, and Plesk update tasks work as expected.
I checked it using the configuration when psa/dumps/* folders are located on the NFS server:
Plesk server:
1. Backups are creaated in /plesk_backups/psa/dumps folder:
# grep DUMP_D /etc/psa/psa.conf
DUMP_D /plesk_backups/psa/dumps
2. psa/dumps/ folder has ownership psaadm:psaadm:
# ls -lad /plesk_backups/psa/dumps/
drwxr-xr-x. 6 psaadm psaadm 8192 Aug 28 10:48 /plesk_backups/psa/dumps/
3. /plesk_backups folder is the NFS share folder:
# df -h | grep plesk_backups
192.0.2.2:/home 37G 1.3G 36G 4% /plesk_backups
4. Ownershipt 997:1000 is used for the directories on the remote NFS server:
# ls -lad /home/psa
drwxr-xr-x. 3 997 1000 19 Aug 27 23:18 /home/psa
5. Backup are created under root:root on the NFS server:
# ls -lad /home/psa/dumps/domains
drwxr-xr-x. 4 root root 44 Aug 27 23:19 /home/psa/dumps/domains
Please sign in to leave a comment.