Skip to content

hyperscale.at

Service-orientation-as-a-Service, SOA, PaaS, IaaS, and Economies of Autoscale

Archive

Tag: unix permissions

Are you getting this error during the installation of Magento?

Fatal error: Call to a member function children() on a non-object …

The most common reason for this error message is that the Magento Installation script is trying to access other scripts which are in a directory that is unreadable by your web server. You probably broke the file and directory permissions for these installation scripts.

You might have better luck with uncompressing the tar.gz archived version of Magento, which you can download from Magentocommerce.com. Tar archives generally are preset with the permissions of the person who archived them, which might be easier since the good folks at Magento probably have a better idea about how permissions need to be set for their software.

If you are using a Magento friendly hosting company like Host Monster, you should be able to simply upload the compressed tar.gz file and uncompress it on the server side with the permissions already set properly.

It’s still a good idea for you to know how to set permissions for web applications on a web server, especially if you run your own VPS or dedicated web server or people are paying you to install/set up Magento for them.

Here’s how to set the file and directory permissions for Magento Manually

Check that all directories inside your magento directory are readable and executable by your web server’s user. Normally the web server runs as either the user apache or nobody. As a side note, it’s more secure to run your web server as it’s own username instead of “nobody”.

For those of you running the lazy (less secure) installation of your web server… The lazy (less secure) way is to change permissions is:
chmod -r 777 /your/magento

Don’t set permissions using the lazy method, because anyone with access to your web server (shell, ftp, or even just web access through a script) can overwrite your magento files and heavily compromise your e-commerce site. It is very important to run an e-commerce web server securely because a compromised web server can send thousands of credit card numbers to thieves before the security breach is noticed. If you are unsure about security, it is recommended that you use a scalable e-commerce service such as Shopify or that you purchase a Magento installation from someone who is seasoned in e-commerce. I can set up the Magento software platform (which supports the hosting of multiple web stores) in about an hour or two depending on your hosting situation. However, if you prefer to and are comfortable setting up e-commerce sites yourself, read on.

Try to limit permissions to only your ftp/shell username and the web server. The way most people handle this is to change the owner of files to their ftp/shell username and set the group to the web server’s group.

For example (assuming your web server runs under the user name “apache”):
chown -r yourname:apache /your/magento

Make files (not directories) readable by your web server:
find /your/magento -type f -exec chmod 640 {} \;

The next thing you should do is set the file permissions for Magento directories to readable and executable:
find /your/magento -type d -exec chmod 750 {} \;

Now set the permissions for directories that need to be writable and executable:

chmod 770 /your/magento/app/etc
chmod 770 /your/magento/var
chmod 770 /your/magento/var/cache
chmod 770 /your/magento/media
chmod 770 /your/magento/media/downloadable

chmod 770 /your/magento/media/import

I got switched to a Xen VPS (debian linux) recently and discovered that some applications couldn’t write to /dev/null. It turns out that /dev/null was actually only readable and writable by root. I logged in as root and changed the permissions so that /dev/null was readable and writable by all.

chmod 666 /dev/null

This solved the problem.

I was still having trouble with some shell accounts, though, because no users could access screen (virtual terminals). The error message was that no PTYs were available. I solved this problem by giving these users access to the /dev/ptmx directory. This directory was initially only readable, writable, and executable by root, but I made it so that anyone in the admin group could read write and execute this directory.

chown root:adm /dev/ptmx

chmod 770 /dev/ptmx

If you want any user to be able to use screen, you will have to do this:

chmod 777 /dev/ptmx