119

It's a Laravel-install related question. I have a public-facing Unix server setup:

<VirtualHost *:80>
ServerAdmin webmaster@mydomain.org
DocumentRoot "/var/www/mydomain"
ServerName mydomain.org
ServerAlias www.mydomain.org
ErrorLog "/var/log/mydomain.org-error_log"
CustomLog "/var/log/mydomain.org-access_log" common
</VirtualHost>

I can serve documents fine out of /var/www/mydomain i.e. http://mydomain.org/test.php with test.php containing:

<?php echo 'test';

works fine.

In bash, with Laravel installed through Composer and looking at the files:

# ls /var/www/mydomain/my-laravel-project

.gitattributes  CONTRIBUTING.md artisan         composer.json   phpunit.xml readme.md       vendor
.gitignore      app             bootstrap       composer.lock   public          server.php

So when I browse to:

http://mydomain.org/my-laravel-project/public/

why does my application report:

Error in exception handler.

in the browser - on a blank white screen? I'm expecting to see the Laravel splash screen.

Moreover, the log files don't reveal anything either.

cookie
  • 2,546
  • 7
  • 29
  • 55
  • PHP version? Can you check your servers logs in `/var/log` and see what, if anything, they have to say. – Jason Lewis Apr 21 '14 at 00:48
  • 3
    What about Laravel's error logs in `app/storage/logs`? And are all the storage directories writeable? – Jason Lewis Apr 21 '14 at 11:05
  • 1
    @Jason Like you said - it was the storage directories. A chmod -R 757 on storage and I can hit the splash screen. +1 and thanks. – cookie Apr 21 '14 at 13:26

6 Answers6

246

The safer option would be to change the group of the storage directories to your web servers group (usually apache or www-data, but this can vary between the different operating systems) and keep the permissions as of the directory as 775.

chgrp -R www-data app/storage

Or with chown.

chown -R :www-data app/storage

Then make sure directory permissions are 775.

chmod -R 775 app/storage

From the Laravel web site:

Laravel may require one set of permissions to be configured: folders within app/storage require write access by the web server.

elpddev
  • 4,314
  • 4
  • 26
  • 47
Jason Lewis
  • 18,537
  • 4
  • 61
  • 64
  • 14
    generally safer to change group owner to the web server and not grant "the world" full access to your files. 775 is the default for directories so that should be enough. chgrp -R apache app/storage – hlev May 11 '14 at 18:22
  • 5
    On Mac, the above commands did not work. However, this command did: `sudo chown -R _www app/storage` (replace _www with your Apache server name if necessary) – Leo Galleguillos Jun 17 '14 at 20:41
  • 4
    And then I had to give the group _write permission_: `chmod -R g+w app/storage` – Daniel A.A. Pelsmaeker Jul 19 '14 at 13:59
  • Thanks, I found this helpful. But, it later creates problems when you're trying to run 'php artisan migrate ...' - as the '/app/storage/' folder gives you 'Permission Denied' error - and you go along fixing all the permissions to owner 'www-data', until you get to '/bootstrap/compiled.php' permissions error. Is it a good idea to set that as well, to owner 'www-data', or set all to 0777 ? – peedeeaay Sep 20 '14 at 17:59
  • If like me you are trying to use MAMP2 and have run into this problem then this solution works. You can find your apache username in MAMP pro in the server/general section under the 'run apache/mysql as user' (e.g. www/mysql, you will then use www as the username). – Phillip Davies Dec 18 '14 at 20:07
  • After one sets permissions corrected delete old sessions in `app/storage/sessions` if they exist – Mugoma J. Okomba Sep 10 '16 at 13:58
  • May go without saying but verify that your `chmod` command actually worked by doing an `ls -l` command afterwards. I was in my VM and the `chmod` silently failed. I did it from the host and it worked, and I'm now the proud owner of a Laravel install – Oliver Williams Mar 07 '17 at 10:12
16

Laravel 5.2

chmod -R 777 storage

Older Laravel chmod 777 app/storage/*

Note if you've got a reasonably locked down dedicated server with no user accounts other than your own, 777 shouldn't pose any more security risk than anything else. There'd have to be some other vulnerability for a malicious user to take advantage of that, and at that point, the 777 permission is probably moot anyway. If however you are on a shared server with other users you do not trust, then you'll need to look into more complicated permissions or check if your hosting provider has already provided isolation.

They should really put this in the quick start docs and provide examples for various setups. You may also have to run it again after the first load as more directories are created automatically. Look in your logs for write errors.

Also your DocumentRoot should be /path/to/laravel-project/public

malhal
  • 26,330
  • 7
  • 115
  • 133
  • 4
    Agreed, or better still a more verbose error message – homerjam Jun 10 '14 at 14:47
  • 3
    They should **not** tell you to go to www.domain.com/project/public because that is not the correct way to run a Laravel application. You should set up your web server to serve public/* and nothing more, with public/index.php being the only entry point for the whole application. You can do that very easily with Apache; if you're using nginx then you probably know what you're doing. And if you're using a cheap cPanel host (my condolences) it's also easy to set up the web root to point to public. – borfast Oct 02 '14 at 17:41
  • 12
    seriously suggesting 777 is just the clearest violation of security principles... – ftrotter Dec 06 '14 at 11:18
  • 1
    I know its a year old but 777 is the worst way to do this it breaks all rules of security like @ftrotter said. – Zac Grierson Oct 15 '15 at 17:11
2

I deleted old sessions inside app/storage/sessions folder and give a 775 permission to app/storage after that it's working like a fire!

chmod -R 775 app/storage
starball
  • 20,030
  • 7
  • 43
  • 238
Abdulaziz Noor
  • 6,413
  • 2
  • 19
  • 21
1

The bandwagon has passed on this a long long time ago, but still I have another piece of advice regarding "Error in exception handler."

I had this happening to me when I ran "php artisan", which is a good way to assess if your environment is working in general.

I ran it and it gave me that error, and I couldn't pinpoint the problem till I edited the artisan file in the root directory of my project and add a try catch statement: 

try {
    $artisan = Illuminate\Console\Application::start($app);
}
catch (Exception $e)
{
    dd($e->getMessage());
}

At which point I finally saw an enlightening message:

string(41) "Connection refused [tcp://127.0.0.1:6379]"

which in my case was a bad redis configuration, but in your case could be anything.

I hope this helps someone, or at least next time I get here I will find my own answer.

NiRR
  • 4,782
  • 5
  • 32
  • 60
  • Thanks. I found out my issue using this - It printed `could not find driver`. And then I found out I had installed `php-mysql`, while `php7.0-mysql` was required. This link also helped me - https://www.digitalocean.com/community/tutorials/how-to-upgrade-to-php-7-on-ubuntu-14-04 – Udayraj Deshmukh Jun 18 '17 at 07:21
-1

The shortest way to solve this is starting artisan with sudo. This will give artisan all the permissions it needs and won't make any security troubles as well.

so instead starting artisan serve with:

$ php artisan serve

try using:

$ sudo php artisan serve

thus you wont have to make any permission changes

Skeletor
  • 3,201
  • 4
  • 30
  • 51
-5

I have the same issue, I just change the permission from directory app/storage to 775 with the chmod command line

Caio Cutrim
  • 9
  • 1
  • 5
    This is already pointed out in the currently accepted answer (and would need the information from that answer about setting the group of the directory correctly to be a fully correct answer.) – Matt Gibson Sep 06 '14 at 17:19