I'm trying to upload and save an image file. This has worked fine in the past, but is now returning an error.
Warning: move_uploaded_file(//home/bitnami/htdocs/lookgram/photos/1/22.jpeg): failed to open stream: Permission denied in /opt/bitnami/apache2/htdocs/lookgram/build/classes/Photo.php on line 138
Warning: move_uploaded_file(): Unable to move '/tmp/phpAyWyw4' to '//home/bitnami/htdocs/lookgram/photos/1/22.jpeg' in /opt/bitnami/apache2/htdocs/lookgram/build/classes/Photo.php on line 138
This looks like a file permssion error, so here is the permissions on the folder:
drwxrwxr-x 6 bitnami bitnami 4096 Mar 15 01:02 photos
Any ideas?
This is because photos/1/ is only writable by root user. For upload to work we need to make the owner of that folder same as httpd process owner OR make them globally writable (bad practice).
Check apache process owner: $ps aux | grep httpd. The first column will be the owner typically it will be nobody
Change the owner of photos/1/ to be become nobody or whatever the owner you found in step 1.
$sudo chown nobody /home/bitnami/htdocs/lookgram/photos/1/
Chmod photo/1/ now to be writable by the owner, if needed [Seems you already have this in place].
$ sudo chmod -R 0755 /home/bitnami/htdocs/lookgram/photos/1/
For more details why this behavior happen, check the manual http://php.net/manual/en/ini.core.php#ini.upload-tmp-dir , note that it also talking about open_basedir directive.
Related
I'm seeing weird Ubuntu permission issues only on a single .csv file when trying to access with php. The file is list.csv, owned by ubuntu:www-data, and ubuntu user is part of www-data group. The rest of the site works fine, no permission issues, but I see the following error when trying to load this file with php:
PHP Fatal error: Uncaught exception 'RuntimeException' with message 'SplFileObject::__construct(xxx/list.csv): failed to open stream: Permission denied'
If i do chown www-data:www-data list.csv, i can load with php. Why is this file not being loaded by php if owned by ubuntu, even if ubuntu is part of www-data group?
Additionally, I can open this file as ubuntu user (vi list.csv) read and write.
Edit: Permissions on the file are: -rwxr-xr-x 1 ubuntu www-data
Edit again: Changed permissions to 0644 -rw-r--r-- 1 ubuntu www-data no luck
Edit some more: File lives in a directory that has x permission:
drwxr-xr-x 3 ubuntu www-data 4096 Jul 28 23:09 content/
Not sure it has anything to do with execute permissions as I can change owner to www-data:www-data and the file gets loaded. It would seem its something to do with user ubuntu owning the file and not www-data
Edit: Its this line of code that errors out, trying to load .csv file into php SplFileObject:
SplFileObject::__construct("xxx/content/list.csv");
I can see in the OP that the only difference between the owner and group is write permission (you have tried xr and r with the group). So, I suspect your PHP is trying to open the file in write mode.
To confirm this try:
$myCSV = new SplFileInfo('YOUR CSV');
$myCSV->isReadable(); // should be true
$myCSV->isWritable(); //expecting this to be false
Edit: If that's whats going with your program you can open the file just in read mode using: $myCSV->openFile('r')
Your server might have the PHP open_basedir parameter set which would prevent access to any files outside of this directory.
To verify this have a look into your relevant php.ini file (for example /etc/php5/apache2/php.ini) and check if the open_basedir line is set.
This may or may not be a duplicate question, partly because the destination folder it's trying to write to, is on a Windows filesystem. I have a script which has a mkdir php function in it, which is trying to create a folder and a file to a mounted windows file system.
Permission on the file
-rwxrwxrwx. 1 apache apache 24850 Jan 6 11:31 fns.php
Permission on the folder is
drwxr-xr-x. 8 a-linux-user root 0 Dec 29 15:55 ACT!
I have the file system mounted on
/media/shared
I'm getting a mkdir(): Permission denied error. I was wondering where I should start debugging the issue.
My httpd.conf file has this permission:
User apache
Group apache
the line or the fstab is
//domain.com/shared /media/shared cifs uid=a-linux-user,credentials=/home/some-dir/.creds,domain=GRM,comment=systemd.automount 0 0
Edit your apache -> conf -> httpd.conf file & change User and Group from daemon to your machine owner name. (in your case: a-linux-user) See if that works.
This is driving me insane. httpd runs as the user apache. I have two directories within /var/www/html -- uploads and photos. Both have group:owner of apache:apache. Both are 755. uploads is writable from php -- photos is not.
Some test code:
var_dump(touch('/var/www/html/photos/_test.log'));
var_dump(touch('/var/www/html/uploads/_test.log'));
var_dump(touch('/var/www/html/uploadsasdf/_test.log'));
And results:
Warning: touch(): Unable to create file /var/www/html/photos/_test.log because Permission denied in /var/www/html/test.php on line 2
bool(false)
bool(true)
Warning: touch(): Unable to create file /var/www/html/uploadsasdf/_test.log because Permission denied in /var/www/html/test.php on line 4
bool(false)
I've confirmed permissions through a shell and GUI interface. I've chowned and chmoded everything again just to be sure. I've renamed the uploads directory to something else and renamed photos to uploads to see if the name of the directory was the key here, but it wasn't. It's the directory itself. The renamed uploads still works with a new name, and the photos directory that is now called "uploads" does not.
Of note, _test.log does not exist in the folders before testing, so it's not like that file has bad permissions or anything.
Interestingly, if I create a new directory, chown it to apache:apache, chmod it to 777, I can't write to it, so something larger may be wrong here; but the question remains: why then does the uploads directory work?
Has anyone seen this behavior before? Am I missing something obvious?
Thanks in advance for any help!
Edited to add more info:
exec('whoami')
"apache"
var_dump(posix_getpwuid(fileowner('/var/www/html/')));
var_dump(posix_getpwuid(fileowner('/var/www/html/uploads/')));
var_dump(posix_getpwuid(fileowner('/var/www/html/photos/')));
all "apache"
All have the same fileperms() value. However, is_writable() is false on all but "uploads".
mkdir('var/www/html/test');
Warning: mkdir(): Permission denied
ls-alF
drwxr-xr-x. 2 apache apache 286720 Nov 22 15:17 photos/
drwxr-xr-x. 2 apache apache 81920 Nov 22 12:06 uploads/
drwxr-xr-x. 2 apache apache 6 Nov 22 10:31 uploadsasdf/
I have called clearstatcache(); I have rebooted the server. What ... on ... Earth?
Since you are using CentOS and and you've tried everything else, my guess would be something related to SELinux. One of the answers from this question may be helpful Forbidden You don't have permission to access on this server. Centos 6 / Laravel 4
Specifically try this to analyze SELinux permissions (ls -lZ) and temporarily disable SELinux:
If you're using CentOS it could be an issue with selinux. Check to see if selinux is enabled with 'sestatus'. If it is enabled, you can check to see if that is the issue (temporarily) using 'sudo setenforce 0'. If apache can serve the site, then you just need to change the context of the files recursively using 'sudo chcon -R -t httpd_sys_content_t' (you can check the existing context using 'ls -Z'.
If selinux is enabled (sestatus will tell you), try sudo restorecon -Rv /var/www/ first. Sounds much like SELinux is getting in the way and you somehow have got a file/directory there which is not labelled correctly. Restorecon will revert labels to default, and -v will show you which labels have been corrected, if any.
Failing that, extended attributes come to mind. do lsattr <filename> and if the output looks anything like ------i-----, the immutable flag is set. Change it with chattr -i <filename> and you're good to go.
When php-script is trying to write to a file:
-rwxr-xr-x. 1 eugene_val eugene_val 8033 Sep 10 10:47 ajax_EN.json
I get an error:
fopen(ajax_EN.json): failed to open stream: Permission denied
I wonder what could be an appropriate solution to it taking security into consideration.
The options I could think of are:
1) chown this file to apache user and chmod it to 700
2) add apache to a group of the file-owner
3) use suPHP and likes(which I would not like to because of the performance hit)
A better choice is to change the file's group to the Apache user group, and set the file to be group-writable:
$ chgrp <apache_group> ajax_EN.json
$ chmod g+w ajax_EN.json
The permissions of the path for this file also matter. Even if you chmod 777 the file, if the user trying to read it doesn't have read permissions for the path, they still won't be able to read the file.
For some odd reason I can no longer access my images in my image folder or any of its contents https://ksc105.kscserver.com/images/list.png or https://ksc105.kscserver.com/images/bold.png. I orginally could not upload files to images and attempted to use chmod a=rw /var/www/images but that did not help. I also upgrade php5 to the latest ubuntu build. What can I do to fix this issue, and what can I do to fix my upload issue?
The current images do not display becuase I get a 403 error:
Forbidden
You don't have permission to access /images/bold.png on this server.
Apache Server at [..].com Port 443
Upload gives me:
warning: move_uploaded_file(/[..].png): failed to open stream: Permission denied in [..]/images.php on line 37
Warning: move_uploaded_file(): Unable to move '/var/tmp/[...].png' to '/var/www/images/nzoom.png' in [..]/images.php on line 37
The [..] is just me taking out useless variables.
PHP 5 on Apache 2 on Ubuntu 9.
I suspect you've messed up the permissions on the directory. You probably want to do:
# chmod 757 /var/www/images
# chmod 644 /var/www/images/*.*
to allow the nobody/apache webserver user to access them
This is a permissions related probably most certainly. I suggest you chmod your:
files to 0644 (or 0666 if Apache is not running as the same [FTP] user)
directories to 0755 (or 0777 if Apache is not running as the same [FTP] user)
This way they will always be executable and you have further write permissions from within your scripts.