Recently, I moved a website to live and all the file related operations stopped working, for e.g., copy, imagecreatefromjpeg, etc due to permissions issue.
All the files are created in files/ directory. I gave it 755 permission recursively for directories and 644 permission to all the files. Still the PHP functions didn't work. It works only if I give 777 permissions (not even 775 works).
I checked the permissions for other live projects. They had 755 for directories and 644 for files, and still they seem to work fine without any permission issues.
Could anyone please explain me the reason for this issue on this specific website?
Thanks
It sounds like an ownership issue.
To test, create a folder on the server with 777 perms (e.g. tmp, perhaps in your document root).
And then create a script (alongside tmp) that does a simple write to that folder.
<?php
file_put_contents(__DIR__ . '/tmp/test.txt', 'hello earth');
Then look at the ownership and permissions of the resultant file.
On my dev server I have Php running under the web server Apache (using mod php) on Linux (Debian). And scripts run as the user 'www-data'. So the key here is that the user www-data needs to be able to write to the folder.
If the folder isn't writable by the web server, then something like the following error is in the apache error logs:
[Tue May 10 08:27:52.404959 2016] [:error] [pid 18] [client 172.17.42.1:59832] PHP Warning: file_put_contents(/var/www/stackoverflow/tmp/test.txt): failed to open stream: Permission denied in /var/www/stackoverflow/so_test.php on line 3, referer: http://localhost/
Try and understand your server environments and unix permissions.
Related
I've set up a LAMP machine with Centos, apache, MySQL and PHP 7.4.
my user via ssh is mformisano, I'm able to login via SFTP with mformisano and browse folders.
It's an intranet machine, so we are not so severe on restrictions, but, if I type the address into the browser I can execute PHP files, but these files are not able to extract files, create files, etc into the var/www/html folder.
Actually the www folder is:
drwxr-s---. 4 apache apache 31 29 ott 22.34 www
inside:
drwxr-xr-x. 21 root root 4096 29 ott 22.34 ..
drwxr-x---. 2 apache apache 6 19 ott 15.54 cgi-bin
drwxrwxr-x+ 3 apache apache 4096 2 nov 10.49 HTML
If I give permission to mformisano, I can browse via FTP, PHP is executed.
If I give permission to apache:apache I cannot browse, PHP is executed.
If I give permission to mformisano:apache I can browse, PHP is executed.
If I give permission to mformisano:mformisano I can browse, PHP is not executed.
I do need to both browse and execute PHP, so mformisano:apache should be the right way, but when I execute kickstart.php (a WordPress plugin that extracts a .jpa archive) this is not extracting and give me an error about writing permissions.
What am I doing wrong?
The PHP files are going to be parsed by Apache. Typically Apache will be running under the user www-data, in any case find out what user Apache is running under and give the appropriate permissions to the user that apache is running as. If you are a single person running the sever I would recommend SFTP login as root user, this will give you permissions to modify whatever you want on the server, but remember to change the owner and groups for any files you create as root user before logging out.
I have Laravel 5.4 installed on my Mac using Composer and MAMP Pro. The installation completed successfully, but when I try to load localhost/lsapp/public, an UnexpectedValueException error is returned. I have checked the file permissions for the storage and logs directories and both are set to 755 using the command line. It seems the log file cannot be written for some reason. Any suggestions?
Full permission denied message: The stream or file "/Applications/MAMP/htdocs/lsapp/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied
in StreamHandler.php (line 107)
When you go into a production environment, I'd recommend the following:
755 permissions for the /log
644 permission for the files inside
For example if you're using apache:
The user owner of the directory (www-data) can read, write and execute.
The assigned group (www-data, where my user is) can read and execute, but not write.
Everyone else can read and execute, but not write.
I just faced the same issue with my installation. Here's what I did to solve it:
Make sure that www-data (or your web server's user) is either the owner or group's owner of the logs directory.
Then make sure that this user have read-write-execute on that folder. On linux I used 770 for that folder. Then laravel is now working fine.
Hope that's help!
In my first PHP script in many years, I'm trying to log an error:
error_log("my error message", 3, $error_log);
I'm getting an error in the general Apache error log:
PHP Warning: error_log(/var/log/apache2/my_php_errors.log): failed to open stream: Permission denied in /var/www/html/blahblah/my_script.php on line 88
This is what I've checked and tried:
Created $error_log with the same ownership (root.adm) and permissions (640) as the Apache error log.
Changed the owner to www-data, which is the user PHP is running as.
log_errors is On.
open_basedir is not set.
Using PHP 5.5.x, so safe mode does not exist.
What am I missing?
Edit: It's able to write to the general Apache error log. The mystery is why it can't write to another file in the same directory with the same ownership and permissions.
Edit 2: Another developer told me that this works on his WAMP, so it's something specific to my LAMP stack or config.
I had the same problem.
https://serverfault.com/questions/831444/php-error-log-per-vhost/831666#831666
touch /path/to/php_error.log
chown www-data:www-data php_error.log
chmod 755 php_error.log
thanks for leading me to the answer!
TL;DR: check that all the ancestor directories allow reads/lists by the web server.
On my system, my equivalent of /var/log/apache2/my_php_errors.log was giving this same error. I eventually did an ls -ld at every level of the path (/, /var/, /var/log/, /var/log/apache2/, /var/log/apache2/my_php_errors.log).
Four of those had permissions that made them readable by the web server. One of them, /var/log/apache2/ did not. When I moved my file out of the apache2 directory, everything started working. E.g. /var/log/php/ and set appropriate permissions/ownership (e.g. 750 by www-data.adm) on the new directory.
prompt> ls -ld /var/log/php/
drwxr-x--- 2 www-data adm 4096 Nov 1 13:31 /var/log/php/
You could also change the permissions on /var/log/apache2/, but that seems like a security/privacy issue. It's safer to make a new directory and leave the existing structure as is.
The reason why the permissions have to change is that it is no longer using some version of syslog to publish to the log files. The syslog variants run as root and accept messages from non-root. But in my case, I was specifying the file from the web server, which made the permissions wrong.
There is a fix that uses syslog so that it could keep the same ownership. I did not try to make that work, as this is for a test server.
This may not have been the problem that you were having, but I'm pretty sure that I was using the default permissions for /var/log/apache2/. So it's quite possible that it was the problem. And even if it wasn't, this is one of the places I was searching for troubleshooting advice. So next time something like this happens to me, I'll have a reminder of what to check.
I have seen many questions and answers on this topic but none seem to help my situation. My PHP code is successfully creating a new logfile, but then cannot access that file to append further info, close it, etc.
I am migrating an application from local XAMPP onto LAMP: hence problem only showing up now due to Windows/XAMPP giving no permission troubles.
I started with a default Bitnami LAMP stack, and then manually setup relevant directory permissions on server:
- my sftp user has rwx on htdocs and assorted out-of-web-root directories
- apache is running as 'daemon' so I have given read & execute permissions to relevant directories for 'daemon' as group
- in most directories I have disallowed write permissions for 'daemon'
- however for my (application generated, internal) logs I have a 'logfiles' directory which has rwx for both my user and the 'daemon' group
- 'other' is -rwx for all
When I run my application it falls over pretty much immediately. The error logs showing fopen failed to open stream: permission denied. However, the permissions indicate that it should have access.
When I check the file involved it has following permissions:
-rw-r--r-- 1 daemon daemon 962 Oct 3 10:14 20151003logfile03-10-33530.txt
This tells me that the file was created by Apache (i.e. by my PHP script) and that it has read and write permissions, from when I fopen() with "w"
EDIT: adding directory info:
Folder level permissions give my ftps user and daemon (group) full rwx access:
drwxrwx--- 2 ftpuser daemon 4096 Oct 3 10:30 logfiles
BUT it can't then fopen with "a"
I am assuming that this IS a file permission problem because:
a) it works fine on XAMPP
b) it states permission error in the error log
However, I can't see why it should be a problem, given directly-specified OS-level permissions ... maybe Apache requires an .htaccess 'allow' on this directory also?
Any ideas?
Clarification re why I don't think CHMOD is the answer (sorry #RedAcid):
CHMOD 777 etc is simply a way to set the underlying permissions I already have. Each digit represents 3 binary chars, so 7 is 111 (i.e. read, write and execute). As you can see above, I have read/write/execute for PHP/Apache on folder, together with read/write for file. What I've read suggests that you need execute at directory level, but not at file level because its not trying to execute the file.
So what am I missing here? Why else might it be denying permission?
use chmod 666 for the file and proper user group permissions. folder where files are located must be writable with chmod 777
OK - I found out the problem was higher level parent directory not having read/execute permissions. Now working! (AT LAST!)
For more detail see this previous question:
PHP fopen() fails on files even with wide-open permissions
After moving php-files from windows to linux(centos) I started getting the following permissions errors:
ERRNO: 2
TEXT: rename(/tmp/wrtwetuti,/var/www/site1/presentation//compile_dir/ee63ba1108c61f830b5d6155f21b1bcd04684f7e.file.category.tpl.php): Permission denied
LOCATION: /var/www/site1/libs/smarty_3/sysplugins/smarty_internal_write_file.php, line 48, at September 9, 2011, 4:05 am
When for testing purposes chmoded compile_dir to 777, the problem goes away.
I wonder if anybody knows a solutions for it.
Would installing suPHP solve this problem?
compile_dir is supposed to be writable by the web server (and also outside your web root). So you should:
move it out of your web root
assign ownership to the web server user
chmod it to 700
The fact that on your Windows install the default compile_dir was also writable by the web server is typical for that OS, and doesn't mean that there is something to fix on Linux.
You can look at this page: http://www.smarty.net/docs/en/installing.smarty.basic.tpl
"Smarty will need write access (windows users please ignore) to the $compile_dir and $cache_dir directories (templates_c/ and cache/), so be sure the web server user account can write to them".
hope this helps.