I have an PHP website on a RHEL5/CentOS dedicated server. The website is located at /var/www/html/beta
I have a script:
/var/www/html/beta/scriptA.php
which calls a function in
/var/www/html/beta/code/inc/functions.php
The function uses move_uploaded_file() as follows:
$status = move_uploaded_file($imagetmp_name,$destinationPath);
Printing these values shows:
imagetmp_name=/tmp/phpiECxB6
destinationPath=in_upload/images/907770756_publicpage.jpg
status=false
Which I thought should have worked since 'in_upload/images' exists:
drwxr-xr-x 5 root root 4096 Oct 19 07:40 in_upload
and
drwxr-xr-x 2 root root 4096 Oct 19 07:40 images
What am I doing wrong?
You don't have writing permisions to in_upload neither images, only for root.
Use
chmod a+w in_upload
chmod a+w images
or change that directories' owner/group to the user, under which is apache running.
example:
chown apache:apache in_upload
chmod g+w in_upload
Related
I am trying to move file to another folder but it gives Permission denied error. Here is the permission of that files.
-rwxrwxrwx 1 root www-data 394 Oct 11 14:40 namechange.xml*
-rwxrwxrwx 1 root www-data 395 Oct 11 14:40 namechange1.xml*
-rwxrwxrwx 1 root www-data 345 Oct 11 14:40 roomchange.xml*
and here id the code that I used to move files
rename("resources/xml_checkin/namechange.xml", "resources/xml_checkout/test.xml")
;
Follow these steps:
Please open your terminal
Login with ssh
locate to the destination file using cd /var/www/html
Give permission to the particular folder using command chmod -R 777 path/folder or command chmod -R 777 path/filename
First try to change the chmod to 775, if it doesn't work then use 777
then try to move your files and see the result.
If issue persists again, let me know.
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.
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.
Under linux, using php 5.3
If I use mkdir in a php script to create a folder, then I have full access on this folder to add files or create folder inside it.
If I then login on the server via ssh, create a second folder, chown(recursively or not) to the exact same user:group as the one created by the php mkdir(), and chmod it to the the same exact permissions as the first folder then trying to access this folder to add a file or create a new folder inside it will throw a permission denied.
Trying to chmod 777 does not work either. I cannot for the life of me figure out the difference between the two :
drwxr-xr-x. 2 amadeous psacln 4096 6 oct. 02:38 test
drwxr-xr-x. 2 amadeous psacln 4096 6 oct. 02:39 testtest
Any idea appreciated.
EDIT AFTER COMMENTS
The apache user is running with the user amadeous in the group psacln.
mkdir() does create the new directory with this user and group
A exec("whoami") returns amadeous as well.
But still no go.
EDIT 2 AFTER COMMENTS ABOUT SELINUX BY GUIDO
ls -Z does give different results although I don't know what to make of it :
drwxr-xr-x. amateous psacln system_u:object_r:httpd_sys_rw_content_t:s0 test
drwxr-xr-x. amateous psacln unconfined_u:object_r:user_tmp_t:s0 testtest
How do I go about fixing this ?
Thanks
The right labeling for files and directories accessible from the httpd apache processes is
httpd_sys_content_t; while the files generated have user_tmp_t:
ls -Z
drwxr-xr-x. amateous psacln system_u:object_r:httpd_sys_rw_content_t:s0 test
drwxr-xr-x. amateous psacln unconfined_u:object_r:user_tmp_t:s0 testtest
To fix the labeling, run (more info):
chcon -t httpd_sys_content_t <directory>
I am trying to read and post back to the browser a file uploaded with the zend framework mechanism.
The file has been uploaded correctly to the desired location and as I have checked by
su www-data
and after an ls and a cat, the web user can read it and modify it properly.
the problem is that inside a controller when I try to:
if(!file_exists($fileName)) {
die("File ($fileName) wasnt set or it didnt exist");
}
I am always getting to die(...), although the $fileName is a string and when I display it's location I can always (as stated before) read it from the command line.
ls output:
$ ls -lah
total 112K
drwxr-xr-x 2 www-data www-data 4.0K 2009-10-07 18:21 .
drwxr-xr-x 3 www-data www-data 4.0K 2009-10-07 13:57 ..
-rw-r--r-- 1 www-data www-data 70K 2009-10-07 17:33 Eclipse_Icon_by_TZR_observer.png
-rw-r--r-- 1 www-data www-data 27K 2009-10-07 18:24 eclipse_logo2.png
Stat output:
stat() [function.stat]: stat failed for .../eclipse_logo2.png
I saw a very similar question to the "try for 30 days" site, so it is not something that has happened to me...
Any ideas?
You have to chmod the newly created file because the file owner created from PHP side will be Apache (group: www-data, httpd, www, or something similar). So next time PHP cannot access the file because www-data owns it and it has wrong permissions.
Here's how you create new files so that you can access them later.
<?php
$path = '/path/to/new/file';
touch($path)
chmod($path, 0777);
// TRY to change group, this usually fails
#chgrp($path, filegroup(__FILE__));
// TRY to change owner, this usually fails
#chown($path, fileowner(__FILE__));