I'm trying to get a simple PHP file to work on a linux Centos 7 server using apache. The problem is that the php code doesn't seem to have permission to write to the folder. The simple test php file below illustrates the problem
<?php
echo shell_exec('whoami');
echo "<br>";
$myfile = fopen("test.txt","w") or die("could not open test file");
fclose($myfile);
?>;
Just to try to get it to work I have done
sudo chmod -R a+rwx /var/www
and yet I keep getting the "could not open test file" error message. What am I doing wrong? Incidentally, the 'whoami' is coming back as 'apache'
**Edit*
In the light of the suggestion below I've done some changes and am now showing the full permissioning for the folders. I've created the group www-data and have added the user apache to it.
[prompt]$ groups apache
apache : apache www-data
For /var/www:
0 drwxrwsrwx. 4 root www-data 33 Jul 27 08:19 www
For /var/www/html:
0 drwxrwsrwx. 2 root www-data 137 Jul 27 12:43 html
The file I'm trying to load:
4 -rwxrwxrwx. 1 root www-data 182 Jul 27 12:40 test.php
It's still not working unfortunately. Might it be something in the apache configuration? Any suggestions would be much appreciated
Here are two options you can try
Option 1
Make sure the group is www-data on '/var/www'.
prompt> sudo chgrp www-data /var/www
Make '/var/www' writable for the group.
prompt> sudo chmod 775 /var/www
Set the GID for www-data for all sub-folders.
prompt> sudo chmod g+s /var/www
Your directory should look like this on an 'ls -l' output.
drwxrwsr-x
Last, add your user name to the www-data group (secondary group).
prompt> sudo useradd -aG www-data [USERNAME]
Option 2
Use the mod_userdir as described in https://httpd.apache.org/docs/2.4/mod/mod_userdir.html
I would recommend the first option as it suits your needs better.
Related
Let's say my storage/logs directory is empty at the moment.
I do a request from Postman and there is an error.
So, Laravel attempts to log it to the storage/logs directory.
Since it is empty, it creates a new file.
Here it is - please notice the owners/permissions:
-rw-r--r-- 1 www-data www-data 9955 Dec 29 10:29 laravel-2020-12-29.log
I read in this answer that the user should be me (let's call my user myuser) and that both me and the group should have read and write permissions.
(and I think that's correct - myuser should be the owner if, for example, I want to run an artisan cmd or sth)
So, I run the following two commands:
sudo chown -R $USER:www-data app/storage
sudo chmod -R ug+w app/storage
Then the permissions of the file become:
-rw-rw-r-- 1 myuser www-data 9955 Dec 29 10:29 laravel-2020-12-29.log
Now, if I try to do a request from Postman again, it still works.
But if I try the next day (or if I delete the file and try again), the new file is created with the initial permissions again:
-rw-r--r-- 1 www-data www-data 9955 Dec 29 10:32 laravel-2020-12-29.log
Why is this happening?
What should be done so that the permissions are set to the proper ones?
You can fix this problem with changing the config of your laravel project
Go to this path config/logging.php and find the line which has daily as key and change it like this for example:
'daily' => [
...
'permission' => 0664,
],
After that the log file generate with this permission
Using the following dockerfile, I'm trying to create a folder which is writable for PHP.
FROM trafex/alpine-nginx-php7:1.2.0
# Add mysql pdo extensions
USER root
RUN apk add php7-pdo php7-pdo_mysql
COPY --chown=nobody:nobody nginx.conf /etc/nginx/nginx.conf
COPY --chown=nobody:nobody public_html/ /var/www/html
RUN chmod 777 /var/www/html/public/ifpos/hits && ls -l /var/www/html/public/ifpos/
USER nobody
During the build this is what I see
Step 6/7 : RUN chmod 777 /var/www/html/public/ifpos/hits && ls -l /var/www/html/public/ifpos/
---> Running in 027345f34fc9
total 8
drwxrwxrwx 2 nobody nobody 4096 Jan 17 04:21 hits
-rw-r--r-- 1 nobody nobody 817 Jan 17 03:04 listener.php
However when I terminal into the container and list the directory, I can see this hasn't been set correctly.
/var/www/html/public/ifpos $ ls -l
total 8
dr-xr-xr-x 2 nobody nobody 4096 Jan 17 04:21 hits
-rw-r--r-- 1 nobody nobody 817 Jan 17 03:04 listener.php
Please help, this is doing my head in!
This happens because /var/www/html is marked as VOLUME in trafex/alpine-nginx-php7:1.2.0 image - https://hub.docker.com/r/trafex/alpine-nginx-php7/dockerfile
You can run the chmod as part of entrypoint script which does the chmod first and then calls the actual entrypoing "/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"
I want to delete deleteme.txt in the Ubuntu web server.
So I made 4.php do the following:
<?php
unlink('deleteme.txt');
?>
deleteme.txt has the following permission status:
-rwxrwxrwx 1 ubuntu ubuntu 19 Jun 12 06:18 deleteme.txt
When I execute "4.php", this error always occurs
Warning: unlink(deleteme.txt): Permission denied in /var/www/html/4.php on line 2
I already tried chmod 777 deleteme.txt and chown ubuntu /var/www/html on the directory which contains "deleteme.txt"
I also tried chown ubuntu /var/www/ on the parent directory of that file.
you need to chown to www-data, thus meaning that the www-data will gain ownership of the file allowing you to delete it through unlink with php.
Like so:
$ chown www-data <file or folder>
I'm having trouble handling the uploaded files on my web server.
First the file is uploaded to the temp server by user "daemon" then I copy the file to www/myapp/files folder by the "www-data" user. Everything works fine, I can read and write to the file, but when I try to delete the file I get an error. Because I'm trying to delete the file as www-data user (php script), but the owner of the file is daemon user.
My question is how can I fix this?
I'm not looking for any chmod or chown solutions, I prefer the solution to be through Apache or some other configuration files.
EDIT:
As requested file permissions:
-rw-r--r-- 1 daemon daemon 41638 Jan 19 08:59 FILE
The parent folder has 0777 permissions
You can add both users to one group like this:
usermod -a -G groupName userName
And then set up r\w permissions for that group
Avoid assumptions
Everything works fine, I can read and write to the file
This indicates that the file permissions themselves, and ownership, permit current usage. If as you say apache is running as www-data, it directly contradicts this:
As requested file permissions: -rw-r--r-- 1 daemon daemon 41638 Jan 19 08:59 FILE
Which would mean the file is not writable to www-data.
Because I'm trying to delete the file as www-data user (php script), but the owner of the file is daemon user.
The above statement is not true - ownership of a file does not affect who can delete it.
I'm not looking for any chmod or chown solutions, I prefer the solution to be through Apache or some other configuration files.
How about not ruling out solutions until you have a choice =)?
Deleting a file uses directory permissions, not file permissions
This is easily verifiable:
-> pwd
/tmp/so
-> whoami
www-data
-> ls -la
total 8
dr-xr-xr-x 2 www-data www-data 4096 Feb 18 14:34 .
drwxrwxrwt 8 root root 4096 Feb 18 14:36 ..
-rw-rw-r-- 1 www-data www-data 0 Feb 18 14:34 a-file
-> rm a-file
rm: cannot remove `a-file': Permission denied
note there is no write permissions to the folder /tmp/so - it's the only permission that matters. Here's another existing answer as a supportive reference.
So given that, the only solution is to ensure that the user attempting to delete a-file has write permission to the containing folder, which means for example:
# assuming daemon is the owner
chmod 7x7 www/myapp/files
^ www-data is not the owner or in the group daemon - so world perms apply
Or
chown www-data:www-data www/myapp/files
chmod 7x7 www/myapp/files
^ daemon needs write permission to the folder too
Or
chown www-data:sharedgroup www/myapp/files
chmod 77x www/myapp/files
^ daemon now reads the group perm, www-data is the owner
(With the upload process running as daemon:sharedgroup)
The above are one-time-only commands that need running; after which there is no need to modify the permissions for any file or folder to permit both www-data and daemon to manipulate files in www/myapp/files.
I'm running as www-data and I'm trying to execute a shell script using shell_exec(/foobar/script/myscript.sh), but I'm getting the following error when the script attempts to write to a log file
cannot create /foobar/foo.log: Permission denied
However, I don't run into any problems if I try running the script directly from the terminal. ie
$ sudo su www-data
$ /foobar/script/myscript.sh
$
Any idea what could be going on here?
I should also add that I added www-data to the group mybar and that this is what's showing up when I list the directory
drwxrwxr-x 3 mybar mybar 4096 May 14 14:18 foobar # ls -l /
-rw-rw-r-- 1 mybar mybar 2824 May 15 09:57 foo.log # ls -l /foobar
I think there can be two options:
web-server and php-fpm are run under different users (by default that should not be). Try echo shell_exec('whoami');
You have added www-data to mybar after php-fpm process had been started so it still "doesn't know" that it is (then I think restart of fpm should help).
This works for me:
sudo chown www-data:www-data -R foobar/
The directory you are trying to create the file in must belong to whoever is executing the command.
You can type:
ls -la
to see who it belongs to.
You should see something like this:
drwxr-xr-x 8 jack jack 4096 Jul 22 11:36 application
When I am logged into my ubuntu machine I am logged in as jack#jack so I can create files in the following directory without issuing the sudo command:
drwxr-xr-x 8 jack jack 4096 Jul 22 11:36 application
because it is owned by the current user.
When you try running a script that is executed by visiting a webpage. www-data is the user that is executing the command so any directory or file that you are trying to create/modify/delete must be owned by www-data.