can you post your restoration log from the wp-content/updraft directory of your restored site using a tool such as pastebin.com?
-
This reply was modified 2 years, 5 months ago by
vupdraft.
Of course, there you go: https://pastebin.com/sxAE58fD
I’ve tried to restore only the uploads folder to make the logs smaller.
It is pretty easy to produce with any mount to uploads folder
I think you are trying to rename the uploads folder which won’t be possible if that’s a mount point of course.
Thanks
-
This reply was modified 2 years, 5 months ago by
rotem925.
UprdaftPlus uses copy and rename (if copy fails)
Are you mounting your containers through a NFS?
Are the wp-content/uploads and wp-content/updraft on the same mounts?
Yes, I’m using NFS as well, actually, that’s EFS on AWS Elastic Container Service.
BUT, that happens also on my local machine, which use a normal mount using docker-compose, no NFS here, same exact error.
I mount only the uploads folder, the updraft folder is inside the container volume (different one), I do not mount it into a different folder.
-
This reply was modified 2 years, 5 months ago by rotem925.
I think the issue is related to file permissions issues between your containers, its likely because
- The
/etc/passwd is different across containers. Creating a named user in one container and running as that user may use ID 700, but that same name in another container with a different /etc/passwd may use a different ID for that same username.
Two processes trying to access the same file must have a matching user ID or group ID.
Or
2. Your two containers are running as different users. Maybe the user/group IDs and/or the USER statement in your Dockerfiles are different, and the two containers are technically running under different IDs.
Hi,
two containers? I only have a single container for WordPress. The permissions are set correctly on the volume. Something I’m making sure of before running the container (again, single container).
If you’re referring to the volumes, both volumes have the same permissions for the user that is running the webserver.
It is actually very easy to reproduce, with any compose stack that includes WordPress.
See this compose I’ve just created for you to test, upload any file, install the plugin, and try to restore, you will reproduce this error immediately.
Let me know if you need any assistance from me with pleasure. And thank you again for your help on this! We really want to apply this plugin to our WordPress sites.
Here is a link to the compose in pastebin:
https://pastebin.com/4wxD91su
Hi, Apologies for the delay.
I’ve asked one of our developers to look into this and will update you when I hear back.
Great, thank you for the response.
Waiting to hear on on this issue.
Rotem
Hi Rotem,
Apologies for the delay,
The development team has made a small tweak to the UpdraftPlus 1.23.12 version, the tweak concerns only the issue you’re currently facing right now, so I would suggest you to download the following UpdraftPlus file, upload and install it on your website and see if you can restore your backups without getting the same error.
Thanks
Anthon
Great news ! Thank you for this quick fix. I will test it right away.
Will this also handle any mounted folder? Say for example the languages folder?
Just checked!! Works perfectly ! I just tested the uploads folder though..
Thanks a lot !
Hi there,
I see a new version without the fix you sent me. When is it planned to be officially released?
Thanks!
Rotem
Hi,
Apologies for the inconvenience and for not adding the fix in the current release of UpdraftPlus. Actually, the fix is with our tester team right now for final test. I will make sure that the fix is added in the next release of UpdraftPlus.
Thanks
Anthon
That’s perfect!! Thank you for this update!
Rotem
Hi @anthoniusalfred checking back, I see another release of updraft, does it include this fix? Couldn’t find this in the ChangeLog.
Thanks,
Rotem
