The fact that it has got part of the way through the extraction process means that the blind login was working, and then not...

You might be best upgrading this time manually to ensure that you are overwriting all Joomla core files with clean ones.

Do you have a cookie plugin in place? I have seen this when the frontend clears the cookies for the site as part of a partially implemented cookies plugin.

This is nothing to do with cookies.

The restore.php is looking for a hard coded password in restoration.php (which is an ini file) that is transient. The password is passed in the json each request and cookies are not used at all.

The most likely cause of this issue is that your webhosts virus scanner or other file monitoring software is deleting restoration.php during the process.

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/23201

Closing assuming it is not a Joomla core issue.

Closing assuming it is not a Joomla core issue.

I had the same problem and the reason was because of no space on host. you can check it too.

Thank you @greenreptile . That was my problem unbeknownst to me. Fixed now and easy upgrade complete.

The underlying problem that trips the installer may not be a Joomla core issue, but the ridiculously uninformative error message definitely is. Requesting reopening.

I had same issue trying update from 3.9.13 to 3.9.14 on Windows server 2016, PHP 7.3 and MySQL 5.7. Invalid login. I was using chrome on Mac Mahaje. I switched my browser to FireFox and was able update without error. Maybe something is up with my chrome install.

I had same issue trying update from 3.9.13 to 3.9.14 on Windows server 2016, PHP 7.3 and MySQL 5.7. Invalid login. I was using chrome on Mac Mahaje. I switched my browser to FireFox and was able update without error. Maybe something is up with my chrome install.

Thanks, this is still relevant, used chrome and received the error.. switched to Firefox and system is updating.. That little piece of information was very much appreciated.

If you run on linux and you serve files from a location under your container's user (apache/nginx), just change the file permission to 7xx (x may be 7,5,4 or 1).
It doesn't matter if you have restoration.php or not (I don't have it).

But annoying issue as it leaves no breadcrumbs.

No idea how or why but I just had this happen to me and I can confirm that as soon as I switched from chrome to firefox it worked perfectly

just a thought: Is your .htaccess optimised to add long expires headers to urls?? Im wondering if the url called that creates the restoration password file is not being "hit" because chrome has it "cached" do to expires headers... we have had this before (and I spent a month fixing) on editing articles.

No .htaccess

One thing I just tried was to use chrome in incognito mode ie no browser extensions. Guess what it worked perfectly

Which also uses a clean cache. I’m convinced this is Google loading a url redirect from cache and bypassing a url that creates the restoration file

I’ll add it on my todo list for 2023 to investigate that theory

Sent from my iPhone

On 20 Dec 2020, at 13:13, Brian Teeman notifications@github.com wrote:


No .htaccess

One thing I just tried was to use chrome in incognito mode ie no browser extensions. Guess what it worked perfectly

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

2021 obviously. Fat fingers.

Hi,

I had the same problem on my local server, just because I didn't change the log Directory : it stays on my production server directory.
So, I've just change this directory and it works well.

Hope it helps :-)