I recently set up my first VPS, and fully self configured PHP, Apache and all that good stuff, but when I tried importing one of my projects that deals with fwrite in it, when I try to do an fwrite, it will not throw an error, but it does not write. The only things I have tried so far was to chmod 777 the folder main folder of the project. This did not fix the issue. Is there anything in the php.ini default set to disallow fwrite? I am able to fopen and fread perfectly fine.
Try putting this at the top of your PHP page.
error_reporting(E_ALL);
ini_set('display_errors', '1');
More than likely you'll find that you have a permission denied message. If not, post the message here (If OP is still around).
A quick fix, perhaps not the most secure option, could be to log in via SSH as super user, run chmod -R 0777 [home directory]
For [home directory] just put the base folder that your files are being served from (www, home, public_html, etc...).
If you find that this works, I'd strongly recommend that you narrow the permissions; at least down to 0755.
The reason why this may work when your previous chmod did not, is that you're trying from SU vs regular user. On my install logging in as root did not grant me the permissions necessary to execute chmod correctly, but did after doing a sudo su. Go figure...
Related
Accidentally i rewrote all folders permission from root.
chown -R www-data:www-data /
Just for example. Luckily i have another server. So i started fix all permissions manually one by one. And now everything seems work fine except for one thing: php can't write files.
I have a suggestion that some php or apache process have wrong permissions.
So symptoms:
The stream or file "/var/www/vhosts/.../httpdocs/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied
Yes. I'm sure that files have correct permissions. Because this recursive process was not so fast to override /var folder too. At least some domain still untouched. So i checked it out.
Maybe it would be helpful to know that i use plesk. Because some .sock files could be located there.
I have no idea what i did but it works now. I hope one day it could be useful for someone too.
Just run script if you use plesk
/usr/lib/plesk-9.0/install_suexec
So in the we could say i just reinstall script.
So I have a PHP file located in /var/www/html/test.php and I have it run the code shell_exec('touch /home/pi/Desktop/test_file')
However, the webpage displays fine but when I check the apache log files, I always get permission denied. I understand that apache is running as www-data user and my main user pi probably have some permission clash (I'm new to this stuff).
I tried many options I found on-line, the most promising was here, which suggested I run the commands:
sudo chown -R pi:www-data /home/pi/Desktop
sudo chmod -R g+s /home/pi/Desktop
...but I still get permission denied. Can anyone please suggest what permissions I may need to still configure? I want to ensure security, but at the same time need my PHP file to be able to create new files. I used the Desktop as an example directory, but really I don't care which directory, I just need a directory. I tried touching a file within /var/www/html, but that was permission denied as well. Thanks!
if your apache process is running as www-data, and the file ownership is pi:www-data, you probably need to run this chmod:
sudo chmod -R g+w /home/pi/Dekstop
First, setting the group as www-data won't matter if the files are not group writable. Mode 755 will ensure apache can read the files, but the www-data user would still not be able to write.
Secondly, using "g+w" adds group write without messing with any of the other bits. [644 becomes 664, and 755 becomes 775)]. This way you can safely adjust permissions recursively, without making files executable that shouldn't be.
Incidentally, sudo chmod g+s ... is probably not what you want. That will instead set the sgid bit, and not the group write bit.
First of all, why the heck are you using shell_exec to create a file? PHP has it's own touch() function that will do that for you. You can also create files just by opening a nonexistent file using certain modes (ie, fopen("myfile", "w"))
Using exec to create your files is surely messing with your permissions.
You need to find out which user PHP is running as and chown to that user. You can find that out by running get_current_user().
Then you need to change the permissions with chmod. There's an example in the comments so I won't repeat it. Good luck. Stop using shell_exec.
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've just uploaded a simple symfony2 app on a production server, and I get this configuration error:
2 MAJOR PROBLEMS
Change the permissions of the "app/cache/" directory so that the web server can write into it.
Change the permissions of the "app/logs/" directory so that the web server can write into it.
editing "app/console", "web/app.php" and "web/app_dev.php" with: umask(0000) doesn't work, and if I right click on that folders with FileZIlla, their permissions are already 777. And so?
thanks...
You need to recursively set the permissions, most likely. I'm guessing FileZilla has that option, if not, ssh into the box, and run (replacing /path/to with the actual path)
sudo chmod 777 -R /path/to/app/cache
sudo chmod 777 -R /path/to/app/logs
Sidenote: setting the permissions to 777 is usually a really bad idea.
umask(0000) doesn't actually increase the permissions available to the script. It just ensures that files & directories created by those scripts are accessible from both the command line and the web server. If you're not using the command line, you probably don't need it at all.
It seems i cannot create files. When i set permissions to 777 On the folder i am trying to create a folder in then the script works fine. If the folder is set to 755, it fails. I do not know much about linux, but i am suppose to figure this stuff out. I have spent a couple hours trying stuff. Does anyone know how to make it so that apache has high enough permissions.
I know it is a permissions and apache problem, i just do not know how to fix this. I have edited the httpd.conf file, but i really do not know what i am doing... Any help? (I saved backup.)
Please stop suggesting to use 777. You're making your file writeable by everyone, which pretty much means you lose all security that the permission system was designed for. If you suggest this, think about the consequences it may have on a poorly configured webserver: it would become incredibly easy to "hack" the website, by overwriting the files. So, don't.
Michael: there's a perfectly viable reason why your script can't create the directory, the user running PHP (that might be different from Apache) simply doesn't have sufficient permissions to do so. Instead of changing the permissions, I think you should solve the underlying problem, meaning your files have the wrong owner, or Apache or PHP is running under the wrong user.
Now, it seems like you have your own server installed. You can determine which user is running PHP by running a simple script that calls the 'whoami' program installed in most linuxes:
<?php
echo `whoami`;
If all is right, you should see the username PHP is running under. Depending on your OS, this might be 'www-data', 'nobody', 'http', or any variation. If your website is the only website running, this is easy to change by changing the user Apache runs under. If you have Debian, like I tend to, you can edit the file /etc/apache2/envvars (as root), and change the value for APACHE_RUN_USER. Depending on your OS, this variable might be set in a different configuration file, so if you can't find it in /etc/apache2/envvars, try to search for the variable declaration by using:
$ grep -R "APACHE_RUN_USER=" .
From the directory all apache-config files are in.
If you're not the only one on the server, you might want to consider creating user accounts for every website, and using something like Apache2-MPM-ITK to change the RUN_USER depending on which website is called. Also, make sure that the user the PHP process is running under is the owner of the files, and the directories. You can accomplish that by using chown:
% chown theuser:theuser -R /var/www/website/
If PHP is running with it's own user, and is the owner of the files and directories it needs to write in, the permission 700 would be enough. I tend to use 750 for most files myself though, as I generally have multiple users in that group, and they can have reading permissions. So, you can change the permissions:
% chmod 0750 -R /var/www/website/
That should be it. If you having issues, let us know, and please don't ever take up any advice that essentially tells you: if security is bothering you, remove the security.
I have a similar problem but in my case I have SELinux running and it failed even with 0777 permission. Turns out I need to explicitly allow httpd to have write access on the directory using:
chcon -R -t httpd_sys_rw_content_t <PARENT_OF_MKDIR_TARGET>
SELinux Troubleshooter may have more details.
On ubuntu you edit /etc/apache2/envvars as Berry suggested.
When you change the Apache user, beware of unintended consequences. One of them is the PHP sessions that may be stored in /var/lib/php5. You may need to change the ownership of that folder too.