• 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

Error occurred during /bin/cp command -- from File Manager

JeffreyZ

Basic Pleskian
I have a client who is unable to use File Manager to edit files.
I am able to view the file but when I try to make a change I get the following error:
Error: Unable to edit file /subdomains/das/httpdocs/dsched.html: filemng: Error occurred during /bin/cp command.

I saw two threads related to this issue. It seems for Plesk 11, one possible solutions is to run recover_plesk_directories which I did. I'm still getting the same error message. I assume I can run that command from any folder within parallels?

Other client's user privileges seem to be ok -- tested a few.

How can I reset the user privileges or at least fix this one user privilege as a work-around?
 
It depends on which user owns the files in question. If they are owned by apache.apache then the site is running in mod_php mode and the files were created by the PHP user, which in that case is apache.

FileManage runs as the FTP username, and can't edit files owned by apache.

The solution is to use PHP in Fast CGI mode, where PHP runs as the FTP user and files created are owned by the ftp user.

However, the drawback here is that you'd need to recursively chown all files and directories in httpdocs to the-ftp-username.psacln and doing so has the potential to cause unwanted side-effects. It is not something to do without testing and some thought.

The other solution is just to change those files the user specifically needs to edit to the ftpuser.psacln but the php script in question may later have problems with those files. It all depends on the script and what it needs to do with those files (i.e. if it only needs to read them then it should be fine).

DO NOT be tempted to chomd 777 which is another option that would solve the problem.

All of the above only applies if the files in question are owned by apache.apache. If it is something else then the problem is not what I think it is and my suggestions do not apply.
 
Thanks for your help. I see the ownership of the subdomain is in fact "apache.apache". I switched to FastCGI. New files created now have the correct permissions. There were not many files on this subdomain so I just saved them as a new file (which got rid of apache.apache) and then deleted the original, and then changed the new file name to the original name. For ten files that seemed the easiest solution.
 
Last edited:
Back
Top