Framework: Error 500 when permission denied

[sdlins]

Error: file_put_contents(/my/project/storage/framework/views/b200e05befac64fdb588e76ea52819e8): failed to open stream: Permission denied

I only can see what is happening when x-debugging. The screen only says 'ERROR 500'.

I have APP_DEBUG=true in my .env file.

Why the exception is not showed for a easier and clearer debugging?

[Modelizer]

Please check file permission on /my/project/storage/ folder! For temporary to get started make it 777 which is not secure. But for permanent solution you need to add your web user. Please review your server setting if this not work.

[sdlins]

Yes, I know this and I had already done this. There is no more problem. But my main point here is: Having debug enabled in Laravel .env, _why_ has it not shown the exception?

I have lost some time to figure out what was happening and, a bit worse, to have APP_DEBUG=true made me look any other things first (server configs, virtualhost, etc) before to look for the error via xdebug since I was confident that the error would be thrown.

[sdlins]

@Modelizer @GrahamCampbell bump

[Modelizer]

Yes Even at my initial stage, i was not able to figure out why laravel is not giving me a hint of a problem? Then after deep thinking and research i figure out laravel is not able to create cache files and all those files which are required to boot up due to directory permission issue or server related problem specific to storage folder. At this time when you see WSOD you need to check PHP log files.

I hope this will help you. 👍

[sdlins]

Maybe Laravel could have an set of specific tests _before_ boot up OR could just to make writable those specific folders by itself. It does not seem so hard to achieve (see Yii2 init) and would avoid those not elegant WSOD.

[Modelizer]

@slinstj Yii is doing lot of stuffs in its init file and laravel handle those things automatically using composer. Right now point is permission and WSOD. As far as i understand monolog give file permission problem when its not able to write a file inside storage/log directory. And i am not sure whether giving those directory 777 rights is save or not. You can add this as a feature on laravel/internals

[lagbox]

Laravel's install documentation:

"After installing Laravel, you may need to configure some permissions. Directories within the storage and the bootstrap/cache directories should be writable by your web server or Laravel will not run."

Laravel Docs - Installation - Configuration - Directory Permissions

[sdlins]

@Modelizer, thanks for explanation. By the way, some "deploy" things are done in composer in Yii although init will certificate everything is fine (maybe the fw has been downloaded or composed in parts, etc). All the time I am trying to undestand why laravel has not that similar simple feature. Now you seems have given the correct answer: "make a feature request in laravel/internals". I had never heard about it but now. So, you gave the reasonable comment. Thanks.

[sdlins]

@lagbox a bit more effort you could understand what is my point. After installation I had done all necessary folders writable. But since it is a "investigating" installation, I changed some folders and files, some of them have lost their "w" permission. This is my point: throwing a exception would advise me instantly. It would be the basic i could hope. It is not a critic to laravel in anyway, it is just a basic thing that i think a good framework like laravel should not have forgotten.

[lagbox]

"This is my point: throwing a exception would advise me instantly."

The exception is being thrown. It is being caught by the exception handler, which is now throwing a new exception do to not being able to write to the log file. That new exception is uncaught and causing the white screen. You are outside of the exception handler at this point (as the new exception now bubbles up out of the handler), which is what displays the exceptions for you.

You would need some additional handler to now catch this exception and so on and so on. It's turtles all the way down.

My previous comment was a lack of effort on my behalf in explaining, excuse me for that. I was trying to highlight the importance of those permissions at all times as the thing that you want to display exceptions to you relies upon them, but that documentation quote has no real explanation of why its needed.

You were pointing out something that seems obvious, no problem there, feedback is always great, needed and requested ;-) (I am sure the core team appreciates all feedback). There is just more involved with this issue than it appears so I thought an explanation of how the permissions relate to the exception handler would be enlightening in this matter.

You can test this out by putting the correct permission on the log file, clearing your views, changing the permissions on the storage view folder to incorrect ones. You should see your view permissions exception being displayed when hitting a page, as it is thrown.

I would recommend opening an issue on the "laravel/internals" repository to open a discussion about the possibilities involved with this.

[sdlins]

I would recommend opening an issue on the "laravel/internals" repository to open a discussion about the possibilities involved with this.

Ok, I will consider that (as I said to Modelizer). Thanks for your explanation.