I upload my laravel 5.6 project on Linux Server but the website is not running in the browser and I am getting the given error. Please Help.
The framework is unable to create a cache of the views from the looks of the logs. You need to update the permissions on the storage folder.
If the storage folder is owned by a different user to your server software (i.e. user is not www-data), you need to set the permissions using:
chmod -R 777 storage
If the storage folder is owned by www-data (or the appropriate system user for your server software), you can use the less open:
chmod -R 755 storage
If you run into permission issues, you may need to prefix the above commands with sudo.
Related
I have a need to make any files that are created in the specific Linux directory to have 777 permission.
I would like to have all the users to be able to do Read, Write and Execute on all files under this folder. So what is the best way or Linux command to make it happen?
What I am doing is that I am spinning off two separate containers one for Nginx server and one for PHP:FPM app server to host Laravel 5.4 app.
Please consider the following scenario. I have a docker application container A (PHP:FPM) which is used to serve the web application files to docker container B (Nginx). Now when I access the website, I am delivering the web pages through the web container. Both the containers are within the same network and I share the volumes from my app container to my web container. But when the web container tries to read the files on the app container I get the error which is something like below:
The stream or file "/var/www/storage/logs/laravel.log" could not be
opened: failed to open stream: Permission denied
So I added RUN chmod -R 777 storage in my docker file.
However it is not solving the issue.
So I also tried using SGID to fix the issue by adding one more line in my dockerfile as RUN chmod -R ug+rwxs storage. Still it is not solving the issue of permission.
On a separate note, funny thing is that on my MAC Docker container this works without any issue ( I mean without adding chmod -R 777 to folder or using SGID for setting permission to a folder in my docker file). But when the same code is run on Linux AMI EC2 instance (Amazon AMI Linux EC2) ... the permission issue start to occur.
So how do I fix this ?
The solution is to launch both containers using the same user identified by the same uid. For instance you can choose root or any uid when running the container:
docker run --user root ...
Alternatively, you can switch to another user, before startup, inside your Dockerfile by adding the following before the CMD or ENTRYPOINT
USER root
I have solved it by figuring out user name under which cache files are created when someone access the application url . And then updating my dockerfile to include statement for SGID ownership for that user on the root of app folder where all source code resides (so all subfolder and files included later in whatever way ... at run-time sometime... are accessible from web container for that user) and then using chmod 777 permission on specific folders that needs to have chmod 777 permission.
I have a AWS ec2 instance with Amazon Linux AMI running. As the web server I installed Apache and the web directory is /var/www/html.
Until now I had the permission for /var/www/html set as 777 under the user c2-user (chmod -R 777 /var/www/html).
I read, that you should usually have set the 644 permission for web access. But as soon as I do that, I get the 403 forbidden error message. What do I have to change?
The difference between '7' and '6' is the execute bit. That's important on directories because it allows other users to enter the directory. Since the dir is opened by ec2-user and Apache runs as another user, the third number (of 777) comes into play.
On individual files it may be okay to use permissions of 644, as that prevents other users from being able to modify the file. This isn't always true, though- executable files need the executable bit and logs need to be writeable by their process.
Here's a quick overview on directories and unix permissions: https://unix.stackexchange.com/questions/21251/why-do-directories-need-the-executable-x-permission-to-be-opene
I wanted to copy my Drupal site to another location (VDS), I got full backup from my provider, (in tar.gz), untarred and ungzipped it, deleted some folders, zipped it again in 7zip format, then copied it with sftp to /var/www on VDS and unzipped, but all permissions now are read-only and so Drupal doesn't work at all cause it cannot acess files.
Can anyone tell when I lost my permissions, the right way to migrate to my VDS or (and) how can I manage with my corrupted-permission Drupal now (maybe I just can change them?)
Read only permission is generally fine for a Drupal site, except for the upload folder (it's nomally called files and in can be in sites/default or in sites/YOUR_SITE_CONFIGURATION_FOLDER or wherever you set it to be in admin/config/media/file-system). The files folder, and every subfolder it contains must be writable from the web server, so if your web server is running as the www-data user (the standard user for Apache in Ubuntu, other systems may differ) you can for example do
chmod -R o+w sites/default/files
chown -R www-data sites/default/files
I can't workout how to solve this problem so wordpress would let me upload themes.
I have a fresh copy of Fedora 17 installed on my dev machine.
I then installed mysql using: yum install mysql mysql-server. Next I installed WordPress which also installs apache and php: yum install wordpress
I can go to http://localhost/wordpress and see WordPress working. But when I try tried to install my theme it asked for ftp credentials. I then updated the wp-config.php file and set the FS_METHOD constant to direct. Now it doesn't ask for ftp credentials but it gives me this error:
Could not create directory. /usr/share/wordpress/wp-content/themes/my-theme-name/
httpd service is running under 'apache' user and 'apache' group. The /usr/share/wordpress/ directory is recursively own by 'apache' user and 'apache' group too. I've even set the permissions to 777 (also recursively) and even then I keep getting the same error as above.
How can I solve this problem?
Fedoras SELinux configuration is most probably blocking the attempts of the webserver to write to the disk. To change the settings for your wordpress folder you can run this command (as root):
chcon -R -t httpd_sys_content_rw_t /usr/share/wordpress/wp-content
No need to do chmod 777 to the whole folder, this is a huge security risk. Of course this is for direct filesystem access, you have to disable the ftp access. For ftp access you will have to look up the right SELinux context.
You got the check these lines in your Wp-config.php (aproximatively line 105) :
define('FTP_USER', 'usr');
define('FTP_PASS', 'P#ssw0rd');
define('FTP_HOST', 'url');
You process of web server is running on apache but Wordpress will use the account define in the wp-config.php . So you got to set the group of your user to get access to these files.
Setting permissions 777 is not a solution, you got to care about it.
I just learned to install Apache 2 on my ubuntu linux localhost for the first time. I'm making it work with PHP5.
I noticed that anytime I want to write to a file or directory, I have to chmod 777 the destination.
But from my experience working on 3rd party hosting solutions, I am generally allowed to write to files and dirs that have 755 permissions.
What can I do on my localhost so that I can write to files and dirs with 755 permissions? If the answer to this is very long, can someone send me a link to a step by step guide to do this?
Here are some simple rules for web site content management (under apache) that most people should follow:
All content should be chown'd & chgrp'd to the same user that apache is running as. On new ubuntu installs , the user and group are both "www-data".
If you want to administer the serving files under your own user group, then you should add youself to the www-data group, and make sure that users in this group have read/write access to all the serving files and directories. The caveat here is that you want to make sure not to create new files as your personal account. These should still be owned by www-data. The easiest way to accomplish this is to create the file as yourself, and then chown it to www-data:www-data.
If you do these 2 things, then you should be able to write to files that are being served by apache. I'm not sure where your document root is, but something like this would likely work for most simple installs:
$ sudo usermod $USER -a -G www-data
$ cd /var/www
$ sudo chown -R www-data:www-data .
You probably can't achieve this because the owner of the file is different than the user trying to perform an action on the file.
the permissions are:
owner-group-everyone
rwx-rwx-rwx
i.e. 111 = 7 which allows read/write and execute.
101 = 5 which is just read and execute
you can't write to the file because your logged in user isn't part of the owner/group that has access to the file.
the final 7 (i.e. rwx-rwx-111(7)) means that globally, everyone has read/write access to that file.
how to fix this
In Linux, you can use the chown or chgrp command to achieve your desired results.
First, you will want to find out as which user your PHP code is running. If you are using mod_php5 (package name libapache2-mod-php5) with Apache to run with the "worker" or the "prefork" MPM, this will probably be www-data.
This is no big problem as long as you only run one web application within the server. However, if you run multiple applications (or scripts that are owned by more than one user), you are setting yourself up for all kinds of security-related "fun".