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.
Related
I'm growing several grey hairs trying to work this one out.
All of a sudden in my Laravel project, I can't upload any files to my symlinked public/storage directly as it's complaining about permissions.
I then 777'ed every single file in the app (I know, I know), and it's still complaining about permissions. I've also run composer dump-autoload, which never seems to do anything but I thought I'd give it a go anyway.
Does anyone know what else I can try? I can verify everything is 777, so I can't see why any permissions would fail...
Gah, sorry guys, this was a bit of a red herring.
777'ing everything wasn't working because the uploaded files were being set to 644 (so my manual 777 was only being applied to files that already existed)
For future reference, if anyone's using Laravel and a queued job can't access a 644 file, set the file to 664 immediately after upload (apache owns the uploaded file, but www-data (or ec2-user) is the one trying to access when queued).
SE Linux might be a possible culprit, because the policies change in some cases, eg. when there are broken modules, it will mess up. that would be setsebool -P httpd_read_user_content 1 (if this should throw an error, manually deleting the broken modules is the only thing that helps).
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 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...
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.
I recently moved my website to a new host and now am experiencing some broken code..
I have an uploading script that is now returning this:
move_uploaded_file() failed to open
stream: Permission denied in *..
I've set the upload directory to 777 which worked fine, but my script is needed to have top level permissions..
(As the script itself sets permission to directories, does lots of copying etc)
Is there a way in apache I can set the PHP script to the owner of all the folders on my server?
Thanks
Also
When looking in phpInfo()
Under
apache2handler
User/Group nobody(99)/99
Is this related?
I wouldn't go that route, just give it permissions to the defined upload_tmp_dir, or define upload_tmp_dir to be a directory you have access to. If it is that directory you have problems with. If the target is the problem, and you've 777'ed it, something fishy is going on.
Do you have ssh access to your new host? The reason I ask is that it's probably not best to use the username/group as nobody, as most other services would use this too. I would change it to something like apache
You can then update httpd.conf, adding in these two lines (reloading the config after):
User apache
Group apache
Then, run chown apache:apache -R dir_name to make apache own it.
well,
When you are trying to set the permission like "0777", you must be running on same authority.
What I mean is.
For example, your script tells to change a folder/file permission to 0777, but the folder or file already has a permission and that is '0755' so you are not authorised to make that change. as the user have only 5 authority.
Either, you need to login to FTP and change the folder permission to 0777 and then you have full control over it or you have to stick with using 0755 or similar.