hmabpera

I tried deleting them but all I have is sftp and it won’t let me do it.

When update plugin moves the files into that backup directory the top plugin owner is still daemon with 775 but all the sub directories and files under it become owned by bitnami with 755.? Bitnami is not in the same group as daemon. Before they are moved from wp-content/plugins all the subdirectories and files are owned by daemon with 775 or 664 for files.

Do you think your cron job to clean up upgrade-temp-backup is having the same problem I have when I try to delete the transient files using sftp?

Thanks, Andy.

Regarding ownership issues, Andy, our system administrator changed the owner of the wp-content plugin trees to daemon. With this done, I could update the ones that needed. it However, the cleanup of upgrade-temp-backups directory was never done after these successful updates, leaving transient files there.
Subsequent update to the plugins with these transient files in upgrade-temp-backups failed! (my guess is that they failed because of the presence of plugins with the same name in the upgrade-temp-backup directory.)

For some reason, the update code which is trying to cleanup this directory is unable to do so. The update process creates these files with owners daemon (top level plugin name directory)and bitnami. (everything under that.)

The files are still in upgrade-temp-backup directory. I don’t know if the cron job you showed me above ran or not. Does it leave a trail?

I tried to update a plugin which doesn’t have an incomplete copy in upgrade-temp-backup directory. I did get a different failure message: “the update cannot be installed because some files could not be copied this is usually due to inconsistent file permissions.” I didn’t expect this one to pass because not all the files being replaced were owned by daemon.
thanks for your help, Andy

Andy, I see a cron job called delete_expired_transients scheduled to run at 03:03:32 on Saturday, December 23. If this is the wp-cron job you’re referring to and it runs weekly there’s a chance it will clear out the upgrade-temp-backup directory tomorrow.

I’m not sure. The plugin updates that succeeded were owned by daemon.
Those updates that are requested now are not owned by daemon so I cannot test the update. I’ll have to get in touch with the system admin who has access to the server to change the owner for these and then try to update these.
thanks again

Thanks, Andy. I have read this artcle before but I’m sorry to say it is beyond my experience. Is it possible that I can set up a cron job to clear out upgrade-temp-backup directory regularly to enable subsequent updates of the same plugin to succeed?

Hi Andy,
I’m hoping you and your colleagues can shed some more light on the logic of the new update plugin code which is preventing me from updating plugins.

the stumbling block for me is the upgrade-temp-backup directory.
Is there a way I can update my plugins w/o using the upgrade-temp-backup directory?

thanks.

Thanks, Michelle. I backed up my plugins before a failed update. When I tried to restore this backup using UpdraftPlus, I lost all of the plugins.
I restored them by downloading the backup zip file and actually cp-ing its plugin folders to wp-content/plugins. these function properly BUT I cannot execute any updates to these.

The permissions seem to be correct 775 or 755 for folders and 664 or 644 for files. we changed the owner of the plugin sub-folders and files to daemon. this allowed one successful update for each plugin but no subsequent ones.

Files were left in the upgrade-temp-backup folder after successful updates. According to the documentation they should have been removed at that time.

Thanks, Andy,

Is this a possible scenario:

1. PLUGIN_NAME plugin owner is daemon

2. PLUGIN_NAME update succeeds

3. successful update leaves previous PLUGIN_NAME folder in upgrade-temp-backup folder with sub files & folders no longer owned by daemon

4. subsequent PLUGIN_NAME update can’t move current folder into upgrade-temp-backup folder because there’s a folder with that name already there (with sub files & folders no longer owned by daemon)

5. this causes error, PLUGIN_NAME update fails,

6. wordpress copies the upgrade-temp-backup/PLUGIN_NAME folder into content-plugins folder, because that’s what it does if there’s an error

7. likewise wordpress deactivates this PLUGIN_NAME plugin

(BTW there is no PLUGIN_NAME.php in the upgrade-temp-backup/ PLUGIN_NAME folders)

Again, thanks for hanging in here with me. It’s hard to figure out how to fix this situation w/o knowing what the update plugin code is doing.

I hear you. What is your opinion of this article:
https://www.smashingmagazine.com/2014/05/proper-wordpress-filesystem-permissions-ownerships/#file-and-folder-ownership-for-wordpress
Again, thanks

this is what I tried before and that caused the failure on the second update of a any plugin. Our system admin changed the owner of all the plugins to daemon. the first update after that (successful) left a directory plugin in upgrade-temp-backup/plugins directory. the second update of that plugin gave the error message: could not move the old version to the upgrade-temp-backup directory (but the file which is now in the contents/plugins directory previously owned by daemon is now owned by “buddy123” as are those other plugins which are in upgrade-temp-backup/plugins. it looks like it cp’ed it there but didn’t connect it to the system.

Do you know why it didn’t it didn’t or couldn’t remove those temporary backup files from that directory after the successful update?

thanks for hanging in here with me.

Thank you, Andy. Your advice is spot on. This problem began when the backup/restore (UpDraftPlus) of my plugins wiped out all my plugins in wp-content/plugins. I unpacked the plugins zip file and cp’ed each plugin from there into wp-content plugins. and activated same. Seemed OK. Everything worked. BUT I couldn’t update any plugins as these requests came in. I was advised to change the owner of all the plugins to Daemon. First update worked. As soon as I had to update the same plugin subsequently, I got the upgrade-temp-backup error along with the deactivate, remove from admin/plugin.php list.

what do you advise? Everything went south when I did the UDPlus restore.
Thanks.

I forgot to mention that after the failed update, there was a message on the plugins page “the plugin PLUGIN NAME” has been deactivated due to an error: Plugin file does not exist” Note again that the plugin file is in the wp-content/plugins directory but gone from the admin/plugins list on our site. Again, thanks for your assistance.

Thank you, Andy, for trying to help me.
I did the initial update from the admin/plugins.php page by selecting the plugin there and choosing Update Now.

Obviously, I don’t understand much about users and owners. Our wordpress installation is on an AWS server. I believe the super user is daemon. when I logon to the WordPress files on the server I use sftp with a username, e.g., buddy123.
Last week I was told to chown the plugin files and sub directories to daemon so the updates would be successful. The system admin did that. Updates worked — until I had to update two of those plugins again this week. These updates failed. Coincidentally, the plugin copy was sitting in the upgrade-temp-backup directory with the PLUGIN-NAME directory owned by daemon but the files and directories under that are owned by buddy123. This followup Update Fails with the error about mving the old version to the upgrade temp backup directory failure.

Two other plugin updates ran successfully today. Neither of them had leftover files in the upgrade-temp-backup directory before they updated but they do now after their successful update. Do you think this should be so?

Interestingly, the plugins that failed had leftover files in that directory but they no longer do have them after the failure. Maybe they got mv’ed to wp-content/plugins because the ones there are now owned by buddy123 but apparently are “invisible” to WordPress, by this I mean the plugins are no longer in my list of admin/plugins and do not function on the website.

Again, I thank you very much for your time and expertise. From your writing on this topic, I determined that you have an understanding of how the “updating plugins” routine really is supposed to work. That is why I am asking for your help.

i am having the same problem. update failed. could not move the old version to the upgrade-temp-backup directory. After that the plugin, Name of plugin, has been deactivated due to an error: Plugin does not exist.

Now the plugin is on the server in wp-content/plugins directory but not in my admin plugin list.

I notice that the plugin was left in this directory from a previous successful update. Could this be the reason for the error.? Why are successfully updated prior plugins now being left in this directory? However they are removed on a subsequent failed update of the same plugin.

plugin was leftover in upgrade-temp-backup after a successful update of same plugin. next time I update same plugin, update fails, plugin gone from upgrade-temp-backup directory, AND my admin list of plugins but still sits in wp-content/plugins, deactivated, gone from website.

upgrade-temp-backup and sub directory owned by daemon and 775 permissions.

How can I prevent this from happening when I update?
How can I recover the plugin that is sitting in the correct directory but now not “seen” by wordpress? The documents you referenced are beyond my experience. Is there a simple way to get back to where I was? thanks.