Support

Admin Tools

#20238 403 Forbidden Access When Trying to perform a Joomla Upgrade

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by on Thursday, 31 July 2014 18:00 CDT

CardOneConcepts
 Hello,

I have set up a site using the htaccess maker and all seems to be going well.

However, today I tried to perform a joomla core upgrade from joomla 3.3.0 to 3.3.1 and I keep getting a 403 Forbidden Access error message when trying to upgrade.

I could be wrong but I suspect it may be the htaccess file is blocking it? Could this be the case and if so do I add some kind of exception files or directory to get it working?

Than you for your time.

dlb
Please double check your Download ID, they changed again when we upgraded this site to Joomla! 3.3. The 403 error is a little strange for that, but we have seen it happen.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

CardOneConcepts
Hi Dale,

Thanks for the quick reply, actually this morning I had to upgrade the Akeeba products and discovered that I had to update the download ID's in order to do so.

How would the download ID's effect the joomla core upgrades?

I did double check the download ID's just incase, and they are current and in place and am still getting the 403 Forbidden Access when trying to upgrade from Joomla 3.3.0 to Joomla 3.3.1 using the joomla upgrade component.

I suspected it was the htaccess maker but maybe not? Any other thoughts?

dlb
My apologies, I misread your initial post, I was thinking about an Admin Tools upgrade.

You can switch back to the standard Joomla! .htaccess file and see if the upgrade works. I don't think that is the problem, but .htaccess files are black magic. The Joomla! Extension Manager is working through www.mysite.com/index.php, which is specifically allowed in the .htaccess file. You run into problems when a .php file is called directly, not through an index.php parameter.

You can use Fix Permissions to make sure all your files are writable. If you get an error with Fix Permissions, then you have an ownership issue and the ftp layer is the way around it.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

CardOneConcepts
Hi Dale,

Sorry for the long gap in a response.I was hoping I had a good solution to this problem but it turns out it kind of shed light on another issue as well, so I am going to lay them both out here instead of creating another ticket since I believe they may be related?

So, as you suggested I did swap out the .htaccess files and was finally able to perform the core joomla upgrade. So for whatever reason the .htaccess maker file is preventing the joomla upgrades from occurring? And for me that would be fine, I could live with having to do this swap out whenever an upgrade or update needs to be performed. However, in the end I am for the most part handing the site off to my client who is not going to understand what an htaccess file even is let alone swap them out via FTP, make updates and the restore the .htaccess maker file again for maximum server protection. Which in the end is what I am trying to achieve. So there must be some settings I can disable or exceptions I can add to allow upgrades and updates to occur and not output forbidden error messages?

So in addition to this issue with the .htaccess file created by the maker, I also discovered that it is preventing front-end cron job back-ups from completing? I tried everything I could to get the front-end backup to work but kept getting failed results. I ran the troubleshooter and tried every recommended adjustment yet no luck? That is until I swapped out the .htaccess files again and ran the cron job using the original joomla .htaccess file. And bam the front-end backups started working again. I then enabled the htaccess maker file and tried it again and for the first few attempts, the fornt-end backups worked. But then after a day or so they were failing again and so I would disable the htaccess maker file again and they would start working again? Very odd and it has me scratching my head as to what to do?

I really would like to retain the added security the htaccess maker can offer but I also want to have automated backups that don't fail. As with the updates issue mentioned above there must be some kind of tweaks I can make to the htaccess maker settings or exceptions I can add to prevent the front-end backups from failing? And I know you are thinking I should probably get a better host that I can set up automated backups using the back-end but unfortunately that is not an option at the moment and I really only have the front-end option for auto backups at my disposal. I have a few other sites using the front-end backup method with the htaccess maker file enabled and I have no problems with those sites so I am at a loss for what could be the problem?

Any assistance with this would be greatly appreciated. Please let me know what information you need? Should I be providing you any screenshots or log files?

Thank you for your time!

dlb
I apologize, I meant to follow up on this ticket and lost track of it. You were the first or second person to report 403 problems that day. It turned out that Joomla! made a change to the Extension Manager which broke the System - Backup before update plugin, which caused the 403 error. You need to upgrade to 3.11.2 to fix that problem. I can't explain why swapping the .htaccess file worked.

About your front end backup, is it starting and not finishing? If so, I need a backup log to see if I can find the issue.

If the backup isn't starting, what command are you using to run it? Since the backup runs through index.php, it shouldn't need any special handling in .htaccess.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

CardOneConcepts
Hi Dale,

I upgraded to the latest version of akeeba backup as you suggested, but have not had a chance to test if it got rid of the 403 errors, but I will most definitely take your word on that and let you know if I run into any issues with future upgrades. Thank you for your help of that!

For the front-end backup issue, yes the process does start but never finishes when the htaccess maker file is in place. But does backup successfully when I convert to the joomla htaccess file.

I am attaching my log file as you requested.

dlb
I can't figure out why the standard .htaccess file would allow the backup to complete. The log doesn't look like anything that would be caused by the .htaccess file, unless you're modifying PHP settings.

The first thing I want you to try is to run the Configuration Wizard. That will recalculate the timing settings in the backup configuration. Then try your backup again. If it does not complete, please post a new log file.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

CardOneConcepts
Hi Dale,

No I have not modified any PHP settings.

I ran the configuration wizard as you suggested and then triggered the cron job, which failed again. I have attached the debug log file as you requested.

Thank you for your time!

CardOneConcepts
Hmmmm? There was an error uploading the log file? I will try compressing it into a zip file and try again.

nicholas
Akeeba Staff
Manager
The .htaccess file seems completely unrelated to the front-end backup issue. I see that it terminates suspiciously close to 960 seconds, without an error. In fact, the step is complete and it returns successfully. However, the remote end does not try to execute the next step. I suspect that your real problem is that the CRON job has a hard time limit between 950 and 960 seconds. When it goes over it, the CRON job is killed. Since the actual backup step already running is NOT part of the CRON job process[1] it runs to completion. But since the CRON job is dead the next step cannot run.

Note 1: This has to do with the way operating systems handle processes. The CRON job process accesses a special URL to step through the backup. Whenever it accesses that URL, a new web server process is spawned to handle it. This new process does not belong to the CRON job process. Therefore, when the system kills the CRON job process the other (web server) process is not killed.

The solution is to ask your CRON job host to give you more time to run it.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

CardOneConcepts
Hi Nicholas,

That all makes perfect sense! I am in the process of contacting the host to see if the time limit can be adjusted!

Thank you so much for your help and time!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!