i have this problem with fopen files. Maybe someone has a solution...
When fopen creates a file via the browser, the file is owned by "nobody", if i run the same script via crontab i get permission denied.
When the file is created by crontab, its owned by my cpanel username and then i cant fopen it via the web browser.
So the problem is that each of the methods used is using a different user to own the files created. How can i go around this? I searched how to run crontab as nobody but you have to be root and it seems complicated. I didnt find anything about running my web pages as my cpanel user. My php script has chmod 777 and the folder where the files are also have 777 just be be sure.
Any ideas? Thanks.
I'm not a sysadmin guru, but if you have access to the server you can try this
Create a new group called "webwriters" and add nobody and yourself to that group
"chmod g+s webwriters" on the directory you write files
"chmod 660" each file so that the owner and the group have write privileges
If you don't have access to the server it's trickier, but solvable. Instead of running the script directly by cron, run the script on the web server itself by downloading the web page using "wget" or alternatively a php script calling "file_get_contents" on an URL. This assumes that the server is not locked down too tight...
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"
I'm codding a php script, using Instagram Private PHP Api.
It's work fine via SSH under "root" user, but when I try to run it via browser or cron, I getting error: Warning: chmod(): Operation not permitted in .....
I guess that something wrong with permissions, but I am not really good in server administration and can't understand what I can do =(
Please help, how I can fix this problem?
Because Apache (or the web server you're using) executes PHP using different Linux user (usually www-data), which obviously have different permission than the user account you used in access via SSH.
To tackle the problem, you first have to know the folder / file you're going to chmod() belongs to who. If it belongs to root, then it's not suggested to chmod via any scripts that is accessible by public due to security concerns.
If it belongs to your user name, say foo, you can change the ownership of the folder / file you're going to chmod() to be accessible by www-data group using chown() in SSH console, then you chmod() command can be executed without problem.
The user that PHP runs as must have permissions to chmod the given file or directory. If you're running this script via CRON, you get to set the user that PHP runs as right in the CRON job. If you're visiting the script in a browser, PHP is likely running as php or php-fpm or the web server user.
Simply ensure that the given file or folder is owned by the user that PHP runs as.
Note: It is not recommended that you run this script as root in CRON.
If you are editing /etc/crontab, make sure the user parameter (the one after week) is root.
If you are editing crontab via crontab -e, add user parameter crontab -eu root.
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.
I am trying to execute a jar file to do a simple query on my HBase database, from a PHP Server, so i can print the results to a webpage.
PHP Server in configured with same username as hadoop user, and same group too.
The PHP exec command is:
exec("bash /usr/local/hadoop/bin/hadoop jar myjar.jar my.package.MyClass 2> php_error.log", $result);
I get this exception when i try to exec the command(in the php_error.log):
Exception in thread "main" java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:1879)
at org.apache.hadoop.util.RunJar.main(RunJar.java:115)
I know its related to permissions, but even with 777 on my HDFS, and on hadoop installation folders, it doesnt work.
Any ideas? Thank you.
Also, where this temp file wants to be created?
Hadoop dir? hdfs? Where?
Edit:
running this locally, it works perfectly! no permission errors!
hadoop jar myjar.jar my.package.MyClass
Your PHP is ok. The problem is, that the command you are running is trying to copy the file to the hadoop.tmp.dir. It's default location is /tmp/hadoop-${user.name}. You have to give the permissions to that folder too, or the full /tmp/hadoop directory recursively
Edit:
Figured out that apache isn't a valid user in that case. The solution is to create a new user, add it to hadoop group, set permissions to jar, and hadoop.tmp.dir and change the webpage owner to the created user
We have an PHP XML parsing script that uploads photos to a folder structure like /content/images/2012/05/31/%object_id%/. This parser runs primarily as a DirectAdmin cronjob. We run into many problems getting the folder permissions right to enable the uploading in that directory for both the cronjob as running the parser via the browser.
According to print_r(posix_getpwuid(fileowner($directory))); the owner of the directory is is the same as get_current_user(). Nevertheless I receive: Warning: mkdir() [function.mkdir]: Permission denied when running the script via the browser. It works fine when running it as a cron job.
All folders have chmod 0777 and new folders are created as such;
mkdir($path,0777,true);
Naturally we have the same permission problems with uploading and/or deleting the files themselves.
Is there any way to enable all the file actions running both as a cron job and through the browser?
We are running Linux with PHP Version 5.2.17.
Couple of thinks to note: get_current_user gets the owner of the .php file (i.e. the script) but NOT the name of the user that is running the php script. Invariably these are different as the file will be uploaded by you (a regular user) and php/apache will run as a different user (often called "apache" or "www".) You need the latter of these two. suggested snippet from the php manual to get this is:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
(http://php.net/manual/en/function.get-current-user.php - see comments)
To solve you current problem, though, my strong suggestion is to run the cron as the same user that the php/apache is running as (check man page on crontab) - the user should be the one in that snippet above, CHOWN the files and directories to that same user (they will currently be root) and to a group that is shared between you and the FTP client. Then make sure the user and group have read+write permissions so you can also edit from ftp. Make sure you change permissions on both directores (775) and files (644) as your script creates them.
Also note that if you mkdir(), then the directory above must also have write permissions for the user (and this might actually be your initial problem, and why only root/cron can write there).