I have a script PHP that to create a folder and some files in this folder. Ok, I can done easily with mkdir in PHP but the folder is owned by www-data it’s weird user or group that I didn't log in. Because that so I can’t modify this folder and files in this folder (delete).
Could someone suggest me how to fix this? Can I create the folder by our current log in user? It’s a public folder for every users (should chmod 775). And this is created folders by PHP script and can have many folder so I dont't want to run sudo chmod all of theses folders every time a new folder is created!
Any folder created by any application running under the http server service will be owned by the user executing such application (or component of the application). That being said, if you're running an Apache HTTP daemon which the child processes owner is the www-data user, any folder created by any php script will be owned by such user.
You'll not be able to chown() any FS entry to other user, since www-data doesn't have permissions to do so. You can change it manually via command line with super user permissions (uid == 0) using the chown command line binary.
Related
I have a folder above the webroot that is used to temporarily store user files generated by a php web application. The files may, for example, be PDF's that are going to be attached to emails.
The folder permissions are set to rwxr-xr-x (0755). When executing a procedure from the web application, the files get written to this folder without any issues.
I have now also set up a cron job that calls the php script to execute that exact same procedure as above. However, the PDF cannot be saved into the above folder due to failed permissions - the cron job reports back a permission denied error.
I have tried setting the folder permissions to 0775 and still get a permission denied. However, when the permissions are 0777, then the cron job then works fine.
This seems very strange to me - why does the cron get a permission denied at 0755 but it works fine through the web app?
The probable answer is that the cron job executes under your user - and the directory is owned by apache (or www-data or nobody or whatever user your web server runs as).
To get it to work, you could set up the cron job to run as the web server user.
Something like this:
su -l www-data -c 'crontab -e'
Alternatively, you could change the permissions to 775 (read-write-execute for the owner and group, and read-execute for others) and set the group ownership of the folder to the user running the cron job.
However, you have to make sure that if you're deleting something or descending into folder which is created by apache, you could still run into problems (apache would create a file which it itself owns, and your user cannot delete it then, regardless of the directory permissions.
You could also look at some stuff like suphp or whatever is up to date - where the web server processes are ran under your username, depending on your system architecture.
It depends on which user you have defined the cronjob.
If you're root (not recommended) it should work. If you're the web-user (e.g. www-data on ubuntu) it should work as well.
sudo su - www-data
crontab -e
Permission are given to user-group-everybody. That's what the 3 characters denote.
Your php script runs as a different user&group than the cron job, so they observe different permissions.
Check chown and chgrp, or try to run the cron job with the same user.
if you are using cpanel to run a php, you can try something like this:
"php /home/algo/public_html/testcron.php" ...
just write: php (the rute of the script)/yourscritpt.php"
Dedicated Linux server running debain LAMP.
I run a PHP script (using a browser) which creates a directory (and various sub directories) in a folder on the same server for subsequent shared use using Dropbox.
The directories are created in /home/dropbox/New_Project_Name/new_folders and should be owned by the user 'dropbox'.
However running the php script causes the newly created directories generated by the script to be owned by 'www-data'
What is the best why of either running the php script from the browser so that it generates the new directories with ownership of user and group 'dropbox' or subsequently running a script to check for www-data ownership and recursively changing files and directories to 'dropbox'
Many thanks for any help.
Not tested, but after creating the folder, you can run another line of code to change the owner/group
// define user and group
$owner = "dropbox";
$group = "dropbox";
$folder = "/home/dropbox/New_Project_Name/new_folders";
// change the owner and group
chown($folder, $owner);
chgrp($folder, $group);
Keep in mind, that it might throw an error, because there are subfolders and the operation fails. A while loop should solve the problem.
There might be an issues with the permissions, up to the server-config
There is another way to run it recursively with the "exec" command.
you can go like this:
exec("chown -R ".$owner.":".$group." ".$folder);
This will change user and group for the folder and all sub-folders. But beware,
using system is "dangerous". You can run any shell-commands. Don't play around with it too much.
OK - finally got this working (thanks everybody) but adding the following to my /etc/sudoers
www-data ALL=(ALL) NOPASSWD: /bin/chown, /home/sites/public_html/change_owner.php
The contents of the PHP file were as in the answer from DasSaffe
Here are 3 options:
Use suEXEC.
Connect to localhost ftp as user dropbox and create directories and files this way.
Set up sudo so www-data user can execute this as root without password prompt: sudo chown -R dropbox /path/to/dir, then just use php's exec function.
This question has been asked a couple of times up here, but I haven't found a solution yet. I have a Fedora 19 LAMP server and I just want to run the simple command: file_put_contents('test.txt', 'Hello there'); in order to confirm that my web server can use PHP to write data to files. I'm having trouble figuring out a proper permissions scheme. To start, just for development, Apache's document root is /var/www/html. This directory was originally owned by a user and group called www-data, but I changed the directory's group to the primary group of the owner of the httpd process, named apache. It is this owner that is active when PHP runs. I've confirmed this with the following:
As you see, the process owner is apache, the current direcory is /var/www/html/php-console. The directory is owned by www-data and members of the group apache have full access to it.
I have tried the following to get PHP to actually create a file in this location, but to no avail:
chmod 777 /var/www/html/php-console
chown apache /var/www/html/php-console
chgrp apache /var/www/html/php-console
cd /var/www/html; > test.txt; chmod 777 test.txt;
Nothing will work while this script is run from the browser. However, when I use file_put_contents with the PHP CLI, it works just like I would expect, provided that the user I'm entering commands as or its group has write permissions to this directory or test file.
So, from the command line, you see how www-data has read, write, and execute permissions to the folder I'm in. posix_getpwuid and posix_geteuid help you to find the owner of the Apache/PHP process, which in this case is the same as the user logged into the console. file_put_contents succesfully writes 8 bytes to the specified file. If I change the group or owner and group to something else, I get Permission denied, which absolutely makes sense.
If this works on the command line, then why not when I really want it to, i.e., while actually serving web pages???
Because you forgot to read the httpd_selinux(8) man page and give the directory the appropriate file context to allow the web server to write files there.
My code gets a permission denied error at the move_uploaded_file() function when I'm trying to save a file into a folder on my server (from the temp folder).
My user has full permissions across all the website directories and files. Is there an apache user that need permissions as well? How do I give permissions to this apache user?
If that isn't the case. Is there a way I can use the php chmod function to fix this problem?
Thanks for the help!
You are correct. The folder you need to move the file to doesn't need you to have permissions, it needs for the web server to have permissions.
Basically you need to figure out what account your web server is running as and give that user write permissions to the destination directory.
To figure out what your web server account name is, try the following command (assuming you're running Linux):
sudo lsof -i tcp:80
You should get back a bunch of lines with a USER column. One will be root, ignore that one. The other user listed is the user under which your web server is running. It's probably something like www or www-data or apache or the like.
After that, navigate to the parent directory of your upload directory and change it's ownership and permissions with the following command:
sudo chown www-data:www-data uploads
sudo chmod u+w uploads
At that point, your webserver user now has access to write to your uploads directory. If you have any trouble, post a comment and I'll try to help out.
I assume you gave the folder 777 permissions? The folder needs those permission.
I have a folder above the webroot that is used to temporarily store user files generated by a php web application. The files may, for example, be PDF's that are going to be attached to emails.
The folder permissions are set to rwxr-xr-x (0755). When executing a procedure from the web application, the files get written to this folder without any issues.
I have now also set up a cron job that calls the php script to execute that exact same procedure as above. However, the PDF cannot be saved into the above folder due to failed permissions - the cron job reports back a permission denied error.
I have tried setting the folder permissions to 0775 and still get a permission denied. However, when the permissions are 0777, then the cron job then works fine.
This seems very strange to me - why does the cron get a permission denied at 0755 but it works fine through the web app?
The probable answer is that the cron job executes under your user - and the directory is owned by apache (or www-data or nobody or whatever user your web server runs as).
To get it to work, you could set up the cron job to run as the web server user.
Something like this:
su -l www-data -c 'crontab -e'
Alternatively, you could change the permissions to 775 (read-write-execute for the owner and group, and read-execute for others) and set the group ownership of the folder to the user running the cron job.
However, you have to make sure that if you're deleting something or descending into folder which is created by apache, you could still run into problems (apache would create a file which it itself owns, and your user cannot delete it then, regardless of the directory permissions.
You could also look at some stuff like suphp or whatever is up to date - where the web server processes are ran under your username, depending on your system architecture.
It depends on which user you have defined the cronjob.
If you're root (not recommended) it should work. If you're the web-user (e.g. www-data on ubuntu) it should work as well.
sudo su - www-data
crontab -e
Permission are given to user-group-everybody. That's what the 3 characters denote.
Your php script runs as a different user&group than the cron job, so they observe different permissions.
Check chown and chgrp, or try to run the cron job with the same user.
if you are using cpanel to run a php, you can try something like this:
"php /home/algo/public_html/testcron.php" ...
just write: php (the rute of the script)/yourscritpt.php"