• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Question autoupdate plesk fail with nfs dump folder

solucionesuno

Regular Pleskian
I have change my /etc/psa/psa.conf DUMP_D and DUMP_D_TMP direcotry to a NAS folder.

Autoupdates fails everytime.

chown: changing ownership of '/nfsbkp/******/mysql.preupgrade.12.5.30-12.5.30.20161215-034720.dump.gz': Operation not permitted

Can be a solution use no_root_squash ? i this case, thene i can have problem to read this files in other server?

Perhaps another solution can be disallow autoupdates an run autoupdates in different time of the bakcups, chaging with an script the dump_d location, and change agan when finish...

Thanks
 
Among other reasons, this issue can be caused by open files, inode, process or concurrent network transmission limits of the NAS device, too. When the NAS device is busy it does not respond, responds with "not permitted" or it does respond but too late, so that a timeout has already expired. I do not know whether that is the case for you, but you might also consider this thought in solving the problem.
 
thanks @Peter Debik

but my problem is simple. When mount nfs system this "route" permisions from root to no_body for security reasons. and i think that it is for not have future problem for read this files in other system.

seems that i can change this with no_root_squash allowing change permissions over nfs. but i am afraid to have problem later to restore this files in another server.

Thanks.
 
@solucionesuno, root has the same uid 0 on all systems, therefore you won't have problems with DB restore on another server (as long as you have root access on it). However, please note that MySQL DB is not the only thing that would need to be "restored" if you're doing it on another server.

Also, NFS by defaults squashes root into unprivileged user to prevent uploading programs with setuid bit set. It has nothing to do with ability to read these files later on other systems.
 
Back
Top