I did an installation of laravel, and copied the files to a xampp hosted folder on the same machine. When I try to visit my index.php file however, I'm getting the following error:
Error in exception handler: The stream or file "/Applications/XAMPP/xamppfiles/htdocs/TestManagement/app/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied in /Applications/XAMPP/xamppfiles/htdocs/TestManagement/bootstrap/compiled.php:8969
I'm always a bit hesitant about changing permissions, as I've done some pretty bad chmodding before. Was wondering if there was a rule of thumb or expected behavior for this. Should this be 777 or 755?
The Laravel and Monolog documentation appear to contain no reference to the 'right' permissions. You can make it work with restrictive permissions, but be aware of all of the users that need access:
the web server user
cron user (if you run artisan commands via cron)
anyone who manually runs artisan commands.
They will each need read/write permissions to the log files.
Always use 777 on app/storage folder
Related
I honestly don't know what I am doing wrong. I have been trying to work on the business logic of a Laravel application I am working on, but now I want to see my views in a browser, and no matter what I do I get an exception relating to the file permissions of storage/framework. The latest one is
file_put_contents(/home/vagrant/Code/bitpaigow/storage/framework/sessions/VMdtCxzQwaGVremFgwFzj9HnNRkvKuDOMzUsWrXP): failed to open stream: No such file or directory
I have so far tried two different servers: Homestead and Laravel's serve command. What I understand is the problem now is my permissions. Homestead, hoping to allow access to those directories from my Laravel app, however, no matter what I do I always run into an error relating to these folders having the wrong permissions.
I have tried chmod 777 storage/framework but I still get the same error. Any help would be great. Thanks.
I have Laravel 5.4 installed on my Mac using Composer and MAMP Pro. The installation completed successfully, but when I try to load localhost/lsapp/public, an UnexpectedValueException error is returned. I have checked the file permissions for the storage and logs directories and both are set to 755 using the command line. It seems the log file cannot be written for some reason. Any suggestions?
Full permission denied message: The stream or file "/Applications/MAMP/htdocs/lsapp/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied
in StreamHandler.php (line 107)
When you go into a production environment, I'd recommend the following:
755 permissions for the /log
644 permission for the files inside
For example if you're using apache:
The user owner of the directory (www-data) can read, write and execute.
The assigned group (www-data, where my user is) can read and execute, but not write.
Everyone else can read and execute, but not write.
I just faced the same issue with my installation. Here's what I did to solve it:
Make sure that www-data (or your web server's user) is either the owner or group's owner of the logs directory.
Then make sure that this user have read-write-execute on that folder. On linux I used 770 for that folder. Then laravel is now working fine.
Hope that's help!
I am working on Laravel 4. On remote server I took backup of old laravel.log and created new one and restored old one again by removing newly created one. Since then I am getting error:
Error in exception handler: The stream or file "/var/www/stage/webapp/app/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied in /var/www/staging_html/webapp/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php:84
I even change mode and but it did not work either. It's not happening across system, just a particular page.
I am on Amazon AWS
You recreated the file, so the permissions have changed, and apache can no longer access it. Run this in command line to set the permissions:
chown www-data:www-data /var/www/stage/webapp/app/storage/logs/laravel.log
That's if you're using apache. It changes ownership of the file to apache (web server). If the web server user isn't www-data. Find out by typing:
ls -l
In the command line to see what user owns the other files in your laravel directory. Replace www-data:www-data with the user that owns the other web files.
To be clear the left side of the colon is user group and the right side is the user. If you have a specific user group that needs access to those files as well like git or ftp, you may need to set it like this:
git:www-data
ftp:www-data
group:user //generic example
It just depends on your access requirements. If you have questions let me know.
I keep getting this issue on EC2. I've a cron that is run by root user. Whenever this tries to access files (fopen in read-only or filesize) in a folder that has 777, it fails with an error similar to "Warning: filesize(): stat failed for /var/www/.."
It is becoming increasingly difficult to predict this behaviour. Has anyone faced similar issues? Or any recommended way of setting up users and groups? I'm running it on a default setup. Safe mode is turned off as well.
Added my comment as an answer :
If the cron job is run by root then it's not a permissions issue (root has access to any file). This error is usually issued when the file doesn't exist.
I am not a php guy but here is my best guess. The directory has 777 permission but what about the file's permissions inside that directory. Have you tried running chmod on said directory with -R option?
From man chmod:
-R, --recursive
change files and directories recursively
I have written a PHP script for file uploading and for testing I gave my upload directory 777 permissions. The script works fine.
Now I want to remove execute permissions for obvious reasons, but once I do that, I get the following error:
move_uploaded_file([filepath]) [function.move-uploaded-file]: failed to open stream: Permission denied
Just taking the permissions down from 777 to 776 causes this error to appear when I try to upload a file. I don't understand why having execute permissions should have anything to do with this - can someone PLEASE shed some light?
Thank you!
A directory must have execute permission to be accessible in Unix & Linux.
Quoting from here:
On a directory, the execute permission (also called the "search bit")
allows you to access files in the directory and enter it, with the cd
command, for example. However, note that although the execute bit lets
you enter the directory, you're not allowed to list its contents,
unless you also have the read permissions to that directory.
I agree with lserni that the fact that revoking execute permission on the directory for O (the third digit) causes the problem is worrisome as it indicates that the webserver is accessing the directory neither as owner nor as member of the group. You should fix that.
Just taking the permissions down from 777 to 776 causes this error to appear
This shouldn't happen. You ought to be able to run with 770 permissions, i.e., the directory should be owned by the Website user ID, with the group of web server.
This way the owner and the webserver are both able to manipulate the directory and the data. Ideally the Web server serving your website ought to assume the same user ID as the website owner, and that way you can keep the directory mode 700 and have it read-writeable and listable only by you.
If the last digit of the permissions is biting you, it means that the server is running with permissions for "everyone", which may be okay for a development site but isn't too good on a shared site (imagine your passwords being readable by any other website owner in the machine).
However, if you're running on a test machine, the 777 permissions are okay. Directory executable bit does not mean executable (a directory can't be executed anyway) but merely 'listable'. Without that bit, you can create and delete files but you can't know whether they're really there, and move_uploaded_files is objecting to this situation.
There are other solutions (e.g. chrooting each virtualhost in Apache); see also What are best practices for permissions on Apache-writable directories?
for removing the execute permissions you need to execute following commands..
chown -R nobody upload_directory
chmod -R 755 upload_directory
The first command changes the owner of your upload_directory and files under it to 'nobody' which is what php operates under. The second changes the upload_directory and files to only allow user access to writing. -R is for Recursive..