Error: utime: Operation not permitted

[junglecat]

I have WHM 11.23.2 cPanel 11.23.6-R27698
CENTOS Enterprise 4.7 i686 on standard - WHM X v3.1.0

I have searched all over the net and can't find a solution to this.

I host people who use a certain php script that I'm a reseller of. This script is updatable from their admin panel.

I've been getting complaints from hosted clients for the last several days. They are getting this error when they try to update their script:

[Install update]
Uncompress update: error
Tar_error.log: /bin/tar: admin/ioncube: Cannot utime: Operation not permitted /bin/tar: admin/cronjobs: Cannot utime: Operation not permitted /bin/tar: admin: Cannot utime: Operation not permitted /bin/tar: fonts: Cannot utime: Operation not permitted /bin/tar: images: Cannot utime: Operation not permitted /bin/tar: includes: Cannot utime: Operation not permitted /bin/tar: mysql_restore: Cannot utime: Operation not permitted /bin/tar: plugins: Cannot utime: Operation not permitted /bin/tar: templates: Cannot utime: Operation not permitted /bin/tar: utilities: Cannot utime: Operation not permitted /bin/tar: Error exit delayed from previous errors

The directories in the sites that get updated have to have permissions of 777 in order for the auto-updater in their admin panel to work. I checked one of the sites that's getting those errors, and the permissions are 777 like they're supposed to be.

Here is an FTP screenshot showing the directories that get updated:

http://i83.photobucket.com/albums/j2...f/ccupdate.gif

The server is bringing the update over from the update server, but then it doesn't get untarred.

Any clues? My wonderful host tried to help, but he's as stumped as I am.

[junglecat]

Can anyone help?

[Infopro]

Sounds like they don't have permission to do what they want to. What script is this? If you're not running SuPHP which it doesn't sound like you are, you should be. Then a user would be able to properly run commands on the files like creating dirctories and unpacking them via a script.

I wonder whats in that huge error log in your picture?

[junglecat]

I wonder whats in that huge error log in your picture?

I don't know. The user brought that over from another host's server.

Ok, umm, suphp won't break people's php scripts? I don't quite understand what it is.

[Infopro]

Older scripts, maybe. Lots of threads about moving to SuPHP on the forums here. You might want to do some reading up first. But that will give users the ability to manage files via scripts, far better. Not to mention making your server more secure.

[junglecat]

I don't see how it could be a server wide problem. The problem is only happening with some sites on the server. The rest of the sites using that script are not having the problem.

[Infopro]

The directories in the sites that get updated have to have permissions of 777 in order for the auto-updater in their admin panel to work. I checked one of the sites that's getting those errors, and the permissions are 777 like they're supposed to be.

On the site having problems, are there any files in these directories now? What is owner set to on those files? What owner on the directories?

I do note that in your picture whatever the script is, the config.inc.php is dated 2005. Looks like old stuff to me.

If it's working on one account and not the other, seems it should be simple enough to compare/go over the differences in settings between the two to track down what's going wrong.

[junglecat]

I fixed it!! I had a sudden brainstorm and did this:

chown -R USER:USER/home/USER/www/scripts
chmod -R go-w /home/USER/www/scripts
cd /home/USER/public_html
chmod -Rf 777 scripts

It worked!

[junglecat]

I do note that in your picture whatever the script is, the config.inc.php is dated 2005. Looks like old stuff to me.

Config.inc is just the database name/user/pass. That doesn't normally change.

[mitul]

Contact the administrator of the server and let him update the script.