I've come across a strange issue with regards to the use of composer in my current PHP project.
Some of the answers on S.O that relate to this issue have been helpful, in the sense that changing folder permissions to 0755 on the root composer folder as well as subsequent sub folders and files, resolves the issue; however this seems to be temporary.
My PHP script breaks at the line where I require("vendor/autoload.php"). It then only resolves when I change the folder and file permissions to 0755; but every new day I find that the issue persists, then I have to set the permissions again. It's as if the permissions on the folders and files reset at irregular intervals.
Intitially I thought this could be an auto-update issue, however from what I've researched, composer does not auto-update itself by default unless manually doing so.
Your assistance will be greatly appreciated. I'm dumbfounded as to why this happens.
Related
I'm new here, i have a problem with Drupal 9.0.3 and I'm not that much of a Drupal expert either.
The problem is this: after i do "drush cache-rebuild", this happen
[warning] unlink(/bitnami/drupal/sites/default/files/css/css_GBUUzqz5ceINiDlSQ1o7Z8ZvirKTZAlcfXIJ2cvHW6Q.css.gz): Permission denied FileSystem.php:124In FileSystem.php line 324: Failed to unlink file 'public://css/css_GBUUzqz5ceINiDlSQ1o7Z8ZvirKTZAlcf XIJ2cvHW6Q.css.gz'.
I also tried to play a bit with the permissions but nothing happens. I honestly don't know which module or modification of the last ones will have led to this sudden error. Thank you for all kinds of support.
You got that warning because the user you are logged in does not have write permission on the folder /bitnami/drupal/sites/default/files/css/. So, drush (running as that user) cannot delete the aggregated css files while rebuilding the cache.
To solve this, you need to set the permissions of that folder to 775 and make sure that the user you are logged in with belongs to the group-owner of it.
I solved with sudo drush cache-rebuild
However, thanks equally to both you guys.
I have my site hosted on GoDaddy and on that site I have a part for uploads, it worked fine until days ago, now it started to return error 6 - Missing a temporary folder for any file I try to upload, I tried several ways to solve it, changing the php.ini and still nothing.
In my PHP file if I use the command file_exists(sys_get_temp_dir()); returns me true, so the folder is there.
If I use the is_writable(sys_get_temp_dir()); command returns me false, maybe there is the problem, but the folder /tmp on my server has permission drwxrwxrwt.
If anyone can help me with this problem, since I followed several tutorials and nothing about the solution.
Some providers do NOT grant access to the initialization file for PHP, but rather customers must use a local php.ini file with only the entries needed and allowed to set in a customer account.
In the server's Site Administration menu -> Server -> PHP Info what does the output show for upload_tmp_dir?
More than likely on a shared host, one cannot access edit the main php.ini, but one can set some things via their own local (in their account) php.ini file with the right 'snippets'.
Good luck, hope this helps.
Well, the problem has been solved and it is more strange than I imagined, I will leave the answer here to help you if someone has the same problem.
It was necessary to execute the command chmod 777 / tmp, but this command could not be executed since it gave an error that the folder was read-only (Ready-Only file system). To resolve this, it was necessary to mount and remount it, but I couldn't do it either, as it wouldn't let me remount the /tmp folder
For another reason I had to restart the server and magically the server let me change the permissions to 777 (from drwxrwxrwt. to drwxrwxrwx.). With that problem solved.
I thank everyone who tried to help.
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).
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.
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>