Support

Admin Tools

#10155 Update problem: Could not open .../index2.php for writing.

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 nicholas on Sunday, 18 December 2011 13:44 CST

Thursday, 15 December 2011 02:35 CST

tcgass
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: (1.5.23)
PHP version: (5.2.9)
MySQL version: (unknown)
Host: (genotec.ch)
Admin Tools version: (2.1.14)


Description of my issue:

I tired to update my joomla version via admin tools but constantly get a "Could not open .../index2.php for writing." error message. This applies as well when trying to update via ftp. So far updating always worked fine... I guess it must be a rights problem, but wonder how to solve this?
Thomas

Thursday, 15 December 2011 02:56 CST

nicholas
Hi Thomas,

We'll try the "shoot'em with a cannon" approach. We'll give everything 0777 permissions, run the upgrade and then fix the permissions:
- Enable the FTP options in Joomla!'s Global Configuration if they are not already activated. Remember to set Enable FTP to Yes. Note: You may have to change the permissions of configuration.php to 0777 before clicking on the Save button in Global Configuration if Joomla! complains that it can't write to the configuration file.
- Go to Admin Tools, Permissions Configuration and set the default permissions (top section of the page) to 777 and 777.
- Go back and click on Fix Permissions.
- Proceed with the Joomla! upgrade.
- If the FTP options were not already enabled, go to your Global Configuration and disable them.
- Go back to Permissions Configuration and set the default permissions (top section of the page) to 755 for folders and 644 for files.
- Go back and click on Fix Permissions.
That's 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!

Thursday, 15 December 2011 03:42 CST

tcgass
Hi Nicholas

wow, that's what I call a fast and perfect support! :-) Thanks a lot for your reply!

I've tried the "canonball" approach, but end up with an "Could not upload media/system/css/mootree.css" error. Since in the first steps the media folder has been set to 777, does this mean that setting the rights within Akeeba Admin tools does not automatically set the same rights to subfolders and files?

Thomas

Thursday, 15 December 2011 03:45 CST

nicholas
Hi Thomas,

Yes, that's the case. And this means that you have some very strange ownership and permissions issues there. The best approach is to ask your host to change the ownership of all files and folders in your web root to your FTP user and their permissions to 0755 for folders and 0644 for files. For them it's a matter of running three commands in the command-line. For you, doing that is simply impossible (it requires having root SSH access to the server).

After your host does that, you can use the FTP method to upgrade your site. If that still fails, check your free disk space. If it's depleted, you won't be able to upgrade your site.

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!

Thursday, 15 December 2011 03:51 CST

tcgass
If you continue with that speed, you will soon give answers before we had time to ask the question :-))) Thanks again for your reply! I will follow your advise and contact my provider to reset the rights according to your information.

Have a great day
Thomas

Thursday, 15 December 2011 03:52 CST

nicholas
You're welcome :) Please let me know how it goes!

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!

Sunday, 18 December 2011 12:33 CST

user6500
Dear Nicholas,

I had the same update problem, 1.5.23 to 1.5.25. Changed all the permissions per the above to 777 couldn't get the FTP update to work and selected 'write directly to files' and the core updated just fine.

When I checked the permissions after the update, they were reset to 755 & 644.

However, a rather basic question. I never set the FTP (see attached). To use your suggested procedure, are you saying to insert, in global config, the name of the FTP host and port from my hosting provider, then name and password? And then go through the permissions routine as described?

Thanks in advance for any insight.

--Ed

Sunday, 18 December 2011 12:36 CST

nicholas
Permissions all by themselves mean nothing. Nada. Zilch. Squat. It's the combination of BOTH permissions and ownership which mean something. Please read the Security chapter of Akeeba Backup User's Guide where I explain all that. This means that, in your case, you should never use the FTP mode because it won't work. If you read the Security chapter, you'll understand why :)

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!

Sunday, 18 December 2011 12:52 CST

user6500
Nicholas,

Thanks for your quick reply. And thanks for the referral to the Security Chapter. Will do; sorry to waste your time.

--Ed

Sunday, 18 December 2011 12:57 CST

nicholas
It's never a waste of time! :) Knowing how ownership and permissions interact is critical to running a site. I mean, certainly, I can look into each support request and give an oracle-style "do this, but not do that" result. The problem is that you won't understand why I said that. On the next site you might ultimately decide to do something insanely dangerous, like using 0777 permissions to work around a problem. This would undermine the security of your site. So, the way I see it, it's in your best interest to get you reading the Security chapter. This will not only allow you to figure these things out yourself, it will –most importantly– give you a better insight on what permissions will do for your particular site, for each and every site you operate. This is the cornerstone of security! Most of the hacks I've seen on real-world sites came to be because the site owner never understood how permissions work.

So, there you have it. I never feel that helping you educate yourself of the basics of security is a waste of time. In fact, if you have any questions, just post back and I will help you :)

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!

Sunday, 18 December 2011 13:20 CST

user6500
Nicholas,

Thanks for the insight and your time. Very much appreciated and I'll go read the sections that I should have read.

--Ed

Sunday, 18 December 2011 13:20 CST

nicholas
You're welcome!

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!

Sunday, 18 December 2011 13:41 CST

tcgass
Hi Nicholas

I still owe you an answer on how it worked out: perfectly! I must say that I really appreciate you support as well as your tools - simply a must have for anyone using Joomla!

Thanks to Akeeba backup and kickstart, I solved my problem in the following way: I made a backup on the remote site, transferred the backupfile to my local installation - run kickstart to have an exact copy locally. I then run the "cannon method" :-), made the update and reversed the procedure: backup of the local installation, erased EVERYTHING on the remote site, transferred teh backup and run kickstart again. So, finally I ended up with a up-to-date installation and all rights set as they should be. Great!

Thomas

Sunday, 18 December 2011 13:44 CST

nicholas
Awesome! I am glad it all works fine :)

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!

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!