I've installed Symfony on Mac Os X and do:
chmod -R 777 app/cache app/log
Try do this:
php app/console cache:clear
And get back error:
[RuntimeException]
Unable to write in the "/Users/anton/Sites/local/Symfony/app/cache/dev" directory
Try to fix it! Thanks!
If you are on Mac you can use ACL as it is explained here.
From the project directory:
sudo chmod +a "_www allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
sudo chmod +a "whoami allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
_www in the first line is the name of which is running the web server
You have to change whoami in the second line as it is you when you type php app/console cache:clear. (usually the name of your home folder)
Apparently your web server (apache?) already created some files or dirs in the cache folder (so they are owned be the web servers user, probably www-data). In this case a chmod isn't enough, you have to execute a chown -R anton app/cache app/log.
To avoid the general problem of different owners of different cache files, your console user and the user executing php for the web server should be the same. There are different ways to accomplish this. You could:
Change your apache configuration, so the apache runs with your user (anton) rather than www-data
Drop mod_php and use php5-fpm instead (and configure it to use your user)
Use fast_cgi
Related
My site runs on php-larvel and nginx as webserver and the root diectory is /public , everything was ok ,but when I wanted to secure my phpmyadmin login url , creating a symlink by this command in /public_html :
ln -s /usr/share/phpmyadmin/phpmyadmin-YOUR-SECRET-CODE
site went down showing 404 , and the nginx shows this error:
2019/04/07 07:09:02 [error] 4163#4163: *110 directory index of
"/home/admin/web/example.com/public_html/" is forbidden
the nginx configuration has already set to serve on /public . I don't know why it is trying to access public_html on requests .
The user that NGINX is running as must be able to access the directories its attempting to read and/or write to. In most cases, NGINX is either running as the user nginx or www-data.
We can check for the user directive in /etc/nginx/nginx.conf by running:
grep user /etc/nginx/nginx.conf
If the return of that command spits out a user, we can then change the ownership of the directories you've mentioned using chown.
chown -R user:group /insert/path/here
So if NGINX is running as www-data:
chown -R www-data:www-data /insert/path/here
If the grep command doesn't spit out a user, we can always see who owns NGINX's directories and we should be able to use that user.
Simply run:
ls -al /etc/nginx
and grab the user from the output.
As a side note, things are a bit different if you happen to be running PHP-FPM with NGINX. In that case, the directories and files should be owned by the user that the PHP-FPM process is running as.
If you are running PHP-FPM, you can cd in to the main directory and check the pool file. If you've not modified anything there for your setup, the default user for PHP-FPM is always www-data, so that should be the user who owns all files and directories.
cd /etc/php/*/fpm/pool.d/
and then:
nano www.conf
I'm trying to run a simple Laravel command line on my Elastic Beanstalk instance: php artisan queue:work
But I keep getting the following error:
In StreamHandler.php line 107:
The stream or file "/var/app/current/storage/logs/laravel.log" could
not be opened: failed to open stream: Permission denied
I've tried every solution I can find on SO (except the chmod -R 777 advice that seems to trail this question everywhere).
I've tried deleting the existing laravel.log and then using touch to create a new one, and then making sure webapp is the owner.
I've also tried:
sudo chmod -R 755 /var/app/current/storage/
sudo chown -R webapp /var/app/current/storage/
When I list the logs directory, everything looks as I think it should:
-rwxr-xr-x 1 webapp webapp 0 Apr 4 14:38 laravel.log
The storage directory also looks fine:
drwxr-xr-x 6 webapp webapp 4096 Apr 3 19:33 storage
But I'm still getting the above error! Can anyone explain why (not just give a solution).
Thank you
So the simple answer is that I was running the command as ec2-user. As a solution, I could either:
Change the ownership of laravel.log to ec2-user
Run the command as the owner (eg. sudo -u webapp php artisan queue:work)
Switch to root with sudo su to see how it would be run during deployment (ie. as root)
Nothing was especially wrong.
When you log into an EBS instance via ssh, you're logged in as ec2-user.
I don't believe the ec2-user is part of the webapp group which is actually executing PHP & apache/nginx.
Try adding your ec2-user to the webapp group by creating an ebextension in the root of your Laravel project under .ebextensions/ec2user.config
users:
ec2-user:
groups:
- webapp
Prove this is the problem by turning off selinux with the command
sudo setenforce 0
This should allow writing, but you've turned off added security server-wide. That's bad. Turn SELinux back
sudo setenforce 1
Then finally use SELinux to allow writing of the file by using this command
sudo chcon -R -t httpd_sys_rw_content_t storage
And you're off!
I'm using the default Apache on Mac, Symfony 2.
Following Permissions issues on Symfony2, I tried rm -rf app/cache/* and chmod 777 app/cache afterwards.
That works. But...
a)
When Symfony 2 writes any cache files first, my user does not have access to the files afterwards. So clearing the cache via app/console cache:clear results in... [RuntimeException]
Unable to write in the "/Workspace/MyProject/app/cache/dev" directory
I tried to compensate by running sudo app/console cache:clear. But then ...
b)
As soon as I clear the cache using app/console cache:clear or sudo app/console cache:clear and then reload the page, Apache can't access the files:
RuntimeException in ClassCollectionLoader.php line 239: Failed to write cache file "/Workspace/yProject/app/cache/dev/classes.php".
I tried to delete the files and set the ACLs granting read and write for both, me and _www via the Mac GUI. But the result was the same as above.
It looks like only the owner (tested using chown) can access the files when apache runs as sudo. And Apache has to run as sudo when using port 80, else apachectl start would throw This operation requires root.. I found out there's tricky ways who to use port 8080 and redirect 80. But I want to understand the basic problem.
Why is it that either apache or me who has access but not both?
Thanks,
Boris
I don't know, what the problem was but I found a sloution. I zpped the folder and unzipped the files. I hoped they would lose all permissions and so they did. The unzipped files work out fine now. If somebody knows a reason, I would still be interested.
I am running Raspbian version 7 on my raspberry pi. I am running owncloud on this. I have mounted an external drive under /media/Owncloud. This is where I have owncloud store all the files. I cannot access this directory. When I try cd /media/Owncloud it gives me the following error:
-bash: cd: /media/Owncloud/: Permission denied
How can I access this directory?
OwnCloud and external hard drives are tricky and you have a permission issue. For some reason, trying to make a link to an external hard drive has issues, so you need to try mounting your external hard drive.
External hard drive - Apply the proper group and read permissions:
chown -R www-data:www-data /media/user/your_hard_drive/owncloud_data/
chmod -R 777 /media/user/your_hard_drive/owncloud_data/
Local hard drive - Apply the proper group and read permissions:
mkdir /var/www/owncloud/data
chown -R www-data:www-data /var/www/owncloud/data
chmod -R 777 /var/www/owncloud/data
Make the mount of local hard drive to external hard drive
mount --bind /media/user/your_hard_drive/owncloud_data/ /var/www/owncloud/data/
Source:
https://manandkeyboard.wordpress.com/2014/09/15/owncloud-and-an-external-hard-drive/
If you just want to cd into the directory, change to root with sudo -i.
In order to access /media/Owncloud, you need to set the proper permissions. Run the command sudo chmod 755 /media/Owncloud(for more security relative to permission 777).
You also may need to allow to webserver to access the directory. In order to do that, run sudo chown -R www-data:www-data /media/Owncloud
Sources:
My own experience and frusteration in running into the exact same problem
http://www.instructables.com/id/Raspberry-Pi-Owncloud-dropbox-clone/?ALLSTEPS A great albeit somewhat outdated guide to set up owncloud on a Raspberry Pi.
The issue is with wrong permissions.
If the webserver runs as user www-data, the mounted folder must be somehow accessible to that user
either that user must be owner of mounted folder and its contents, and have the "user" permissions, or
the the folder must be accessible to the group the webserver user is in (usually www-data).
To see the current permissions use the ls -l command.
To change the owner use chown command,
to change the permissions for the user-owner, and group-owner, use the chmod command,
or just use Midnight commander (mc) or some GUI to do that.
If you are mounting the external volume through /etc/fstab check the options in there. I would not recommend using the volume with some dynamic mounting (like the file managers do (gvfs-fuse)) if is a key folder for a webserver with ownCloud and you need to have it auto-mounted on boot, as some specific user that the webserver is run as.
I have an experience with having the ownCloud data folder on /srv/data (also ownCloud 7.0 on Ubuntu Server 14.04 VPS), the permissions are 770 and the owner is www-data:www-data, and in the ownCloud config file, I use the line
'datadirectory' => '/srv/data',
I would not recommend using 777 permissions, as it is not a good security practice in general.
Apache is running, localhost is working, if I put an index.html that works as well. However I can't access any folders (my websites) within the document root, which is /Users/Me/Sites
I get a forbidden error when I try to access these.
What's going wrong?
You should check the permissions of your home folder and your sites directory to make sure that they allow Apache access.
You could check the permissions, or just run (in a Terminal)
chmod o+x $HOME
chmod -R o+rX $HOME/Sites