Problem installing Elgg 1.7.12- no clue why it isn't installing

I have been trying for hours to install Elgg on my new domain. I have read every discussion I could find relating to Troubleshooting Elgg Installation but nothing even sounds like my problem. I am pretty sure I followed all of the instructions correctly but for some reason I can't get Elgg to work. I have made a few other websites, but installing that software was simplier than Elgg because my host (Dreamhost) had a "One-Click-Install" for the otehr software I used.

This is the steps I took:

I downloaded the most recent Elgg download.

I unzipped it.

I used the webftp program on Dreamhost to upload the Elgg directory onto my website in the root directory (I want the main page of my website to be Elgg).

I created a MySQL database.

Dreamhost suggested I name the database sigmicron_elgg so I did.

I changed the name of the directory in my FTP to sigmicron_elgg.

My website still has the standard "Coming Soon" page provided by Dreamhost.

I tried installing the Elgg software in my FTP like this:


Then I went to and the page looked like this:


So I deleted that directory.

I don't know what the problem is

  • I'm not sure. I contacted Dreamhost and they said this:

    "Unfortunately, there is a 2MB upload limit on our webFTP interface."

    If I try to upload the zipped file and then unzip it on the webFTP and it doesn't work I would have to start over manually installing each file. Do you think it would work? Or should I just continue to go through each file manually? (I am on mod/friends right now so maybe I am about halfway through all the files)

  • The 2 MB upload limit surely makes it more difficult. You could try to upload the files again after unzipping the archive locally (this time to the correct location...), but if the upload tool misses files (again) it surely is quite annoying. Sorry, but I don't see any other option to find out if all files are on the server quickly.

  • I finished manually going through each file and am doing the Elgg start up now. the Elgg Installation Wiki says to create a data directory, which I did, and "to make sure the web server Elgg is running on has permission to write to and create directories in it" ( How do I do that without chmodding it to 777? It says "Setting your data directory to 777 will work, but it is insecure and is not recommended." I do not want to do anything which would make my website insecure. It gives a link telling how to fix it but I don't know what to do.

  • It's difficult to give a general advise regarding file/directory permissions, because it highly depends on the configuration of your server which settings work and which don't. In general, as long as you create the data directory outside Elgg's installation path (i.e. outside the directories that are accessible via Internet), the 777 permissions are not that much of an immediate problem. For example

    /home/sigmicron/ would be your Elgg root directory and

    /home/sigmicron/elgg-data would be the data directory. In this case I would expect you are on the safe side.

    If you don't want to use 777, you might want to talk with the support of your webhoster, because in this case, the file permissions and file ownership needs to be adjusted depending on the configuration of the webserver.

  • I contacted Dreamhost and am waiting for a reply now. Thank you for all your help

  • Dreamhost said this:

    Unfortunately we aren't able to provide support for custom installations like what you're descirbing. That being said when php scripts are parsed and executed they are run under your own user, or the 'dhapache' user depending on your domain's hosting settings. Setting group permissions to allow writes is usually enough for most applications. If you have any other questions you might find the information at this wiki page helpful when it comes to Unix permissions:

    So should I set the permissions to 775? Is that secure? I searched on google to see if 775 is safe and I couldn't find much but I read this:

    The difference between 777 and 775 is the writable attribute for the world-group. The big risk with 777 is that any user on your server can edit the file. 775 does not have this risk.

    Don't erroneously assume that the "world writable" flag means everyone can write to the file - only the users on that server can. So on a private server, this poses less risk.

    One of the biggest risks is that any script on the server now can write to the file - one "weak" script (known or discovered exploits) can compromise the entire server. If the file is 775, and the webserver-user (usually wwwrun with apache) is in the file's group, it can also write to the file. In this case 775 poses the same risks as 777...

    I don't really understand this? Does that it mean it is not secure?


  • I've set 777 for the data directory and I don't think there's a too high risk because the data directory is not accessible via Internet anyway but only on the server locally. Setting 775 might increase security additionally as it also blocks access from other user accounts on the server that are not in the same group. But in a usual server setup you can't access the home directories of other users anyway. If you want to be on the safe side you can try 775 and see if it works for Elgg. Otherwise use 777.

    Btw. I just read on another thread that Elgg 1.7.12 apparently has a very annoying bug that might make an installation quite unusable (I haven't tried it out myself yet). Elgg 1.7.13 should be released in a few days at the latest and this bug should be fixed. You might still be able to finish at least the installation of Elgg 1.7.12 but I would advice to upgrade to 1.7.13 as soon as it's been released.

  • 755 is the most secure setting when you can have the data directory owned by the web server user. If you cannot change the owner, but can change the group (or share a group with the web server user), 775 is the next most secure. 777 is the least secure but hosting providers generally sandbox accounts from each other. If the hosting provider did a good job, you should be fine.

    All of this assumes that the data directory is located outside your web server's document root.