I'm a bit confused here in Symfony functionality terms. I have a website which is supposed to write sessions in /var/lib/php/sessions/. I'm confused right there, because in /var/www/html/myproject/ everything is recursively property of www-data:www-data (yes, I'm using Apache). However the owner of /var/lib/php/sessions/ is root, so when Apache tries to write there, I get a 500 server error regarding writing permissions in that directory.
I have divided opinions here. Some people advice me to modify config.yml to manage sessions inside the project directory, while other people say that is a really bad practice. But, how do I get everything targeting /var/lib/php/sessions/ without that file permission error?
Here's what I get via Apache URL:
Oops! An Error Occurred
The server returned a "500 Internal Server Error".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.
Here's what I get via php development webserver:
Warning: SessionHandler::read(): open(/var/lib/php/sessions/sess_u3eg1842nlpkbm0rvddrq37dc2, O_RDWR) failed: Permission denied (13)
500 Internal Server Error - ContextErrorException
I really hope you can help me.
In order to create a file the user must have write and execute permission on the directory.
mkdir /tmp/foo
chmod 300 /tmp/foo
touch /tmp/foo/bar
test -e /tmp/foo/bar
In your case setting the 'other' permissions to 3 would allow www-data to write to it. chmod o+wx /var/lib/php/sessions/
In order to remove a file the user must also have write and execute permission on the directory.
In order to list the file names in a directory the user must have read permission on the directory. Note that if you know the filename it's not required to have permissions for listing the directory.
In order to list the properties of a file the user must have execute permission on the directory.
On my computer the permission for /var/lib/php/sessions is drwx-wx-wt. The t indicates execute & sticky bit. Sticky bit for directories means only the owner can delete it.
See Unix File and Directory Permissions and Modes by Wayne Pollock for more info.
Related
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
I see that similar questions have been answered on Stack Overflow, but the solutions haven't fixed my particular problem, so I have to ask...
I have an app that needs to make directories and modify files outside the site directory. This works find on the production server.
After spinning up a test server with the exact same version of Ubuntu and PHP, I'm getting errors on the staging server when it tries to open files or create directories.
Here are the errors:
mkdir() [http://php.net/function.mkdir]: Permission denied
fopen(/root/Dropbox/Backend/Booth-01/settings.sh) [http://php.net/function.fopen]: failed to open stream: Permission denied
Things I have tried:
checking the username running the application (it's www-data)
changing the owner of the external directory recursively to www-data
changing permissions on the directory to 777 (I know, this is a bad idea, but I was just trying it to see if that would help until I figured out what the issue was and will change the permissions to something more restrictive once I get it working)
checking the umask value. It was set to 0002, which shouldn't give me problems. Just for kicks, I tried changing it to 0000 and it didn't help.
checking to make sure PHP's safe mode wasn't enabled.
checking to make sure that nothing was specified in open_basedir. In any case, if that was the issue, it would throw a different error message.
I can't think of what to try next and I'm hoping that someone else is seeing something that I'm not.
Ubuntu 12.04.5 x64
PHP 5.3.10
It's not only the folder itself you have to have permissions on. You should also check the parent folders. I think, if you check this, this will fix your problem.
If this is an external drive (see if it shows up in mount) then you may have to remount it. An auto-mounted external drive can thwart permissions
sudo umount <moint-point>
sudo mount /dev/<device> <new-moint-point>
I have written a PHP script for file uploading and for testing I gave my upload directory 777 permissions. The script works fine.
Now I want to remove execute permissions for obvious reasons, but once I do that, I get the following error:
move_uploaded_file([filepath]) [function.move-uploaded-file]: failed to open stream: Permission denied
Just taking the permissions down from 777 to 776 causes this error to appear when I try to upload a file. I don't understand why having execute permissions should have anything to do with this - can someone PLEASE shed some light?
Thank you!
A directory must have execute permission to be accessible in Unix & Linux.
Quoting from here:
On a directory, the execute permission (also called the "search bit")
allows you to access files in the directory and enter it, with the cd
command, for example. However, note that although the execute bit lets
you enter the directory, you're not allowed to list its contents,
unless you also have the read permissions to that directory.
I agree with lserni that the fact that revoking execute permission on the directory for O (the third digit) causes the problem is worrisome as it indicates that the webserver is accessing the directory neither as owner nor as member of the group. You should fix that.
Just taking the permissions down from 777 to 776 causes this error to appear
This shouldn't happen. You ought to be able to run with 770 permissions, i.e., the directory should be owned by the Website user ID, with the group of web server.
This way the owner and the webserver are both able to manipulate the directory and the data. Ideally the Web server serving your website ought to assume the same user ID as the website owner, and that way you can keep the directory mode 700 and have it read-writeable and listable only by you.
If the last digit of the permissions is biting you, it means that the server is running with permissions for "everyone", which may be okay for a development site but isn't too good on a shared site (imagine your passwords being readable by any other website owner in the machine).
However, if you're running on a test machine, the 777 permissions are okay. Directory executable bit does not mean executable (a directory can't be executed anyway) but merely 'listable'. Without that bit, you can create and delete files but you can't know whether they're really there, and move_uploaded_files is objecting to this situation.
There are other solutions (e.g. chrooting each virtualhost in Apache); see also What are best practices for permissions on Apache-writable directories?
for removing the execute permissions you need to execute following commands..
chown -R nobody upload_directory
chmod -R 755 upload_directory
The first command changes the owner of your upload_directory and files under it to 'nobody' which is what php operates under. The second changes the upload_directory and files to only allow user access to writing. -R is for Recursive..
I'm trying to troubleshoot this error, but I have had no luck.
Warning: mkdir() [function.mkdir]: Permission denied in Users/myuser/Sites/mysite.me/git/framework/libs/smarty/sysplugins/smarty_internal_write_file.php
I keep getting the mkdir() [function.mkdir]: permission denied error in one particular folder. I have made sure to chmod 777 foldername through linux and it still hasn't worked. I am doing this on a local machine through XAMPP. I've also made sure to make sure it is read and write for everyone from a GUI standpoint. I'm still having no luck. Thoughts?
I'm getting a warning for mkdir, chmod, touch, rename, and include.
For anybody who ends up here from there:
https://stackoverflow.com/questions/12801733/php-upload-outside-web-root-permission-denied-to-mkdir was marked as an exact duplicate of this thread. That thread was also cross-posted to the AWS forums where it received an answer.
That said, the accepted answer here is actually wrong. (Maybe not wrong wrong, but still somewhat wrong.) The better way to approach this is to have the owner/group of the Apache process match the owner/group of the directory that you want Apache (and in-turn, PHP) to be able to write to.
This way, you're granting access to specific, managed users instead of opening up your file system permissions too broadly.
Add write permissions for all users (or at least webserver user eg. www-data for apache) in which mkdir is creating the directory.