I have a laravel project on an ubuntu virtualbox.
I used to run composer update and all worked fine. I don't know of any changes that could have affected this but now when I run composer update I get
file_get_contents(/home/user/.composer/config.json): failed to open stream:
Permission denied
Does anyone know why? When I run sudo composer update , it works.
Your permissions got changed somehow (perhaps not related with running composer). Setting the owner of that file as your user should fix the issue:
sudo chown user /home/user/.composer/config.json
The above assumes that the username is user from the home path. As a side note, it works when running it as a super user using sudo because there's no permissions restrictions in that case.
It seems you don't have valid permissions for this file. Try running:
sudo chmod 0777 /home/user/.composer/config.json
EDIT
Of course, you should do it only in development environment (you mentioned you use Virtualbox). You should not do it in production environment.
Run below command.
sudo composer update
Related
I am trying to install create a new app in Ruby on Rails and I cannot get passed this error:
$ gem install pg
ERROR: While executing gem ... (Errno::EACCES)
Permission denied # rb_sysopen - /Users/stormyramsey/.rbenv/versions/2.3.2/lib/ruby/gems/2.3.0/gems/pg-0.21.0/.gemtest
Its a permissions issue. You could fix it with this:
sudo chown -R $(whoami) /Library/Ruby/Gems/*
or possibly in your case
sudo chown -R $(whoami) /Users/stormyramsey/.rbenv/versions/2.3.2/lib/ruby/gems/*
What does this do:
This is telling the system to change the files to change the ownership to the current user. Something must have gotten messed up when something got installed. Usually this is because there are multiple accounts or users are using sudo to install when they should not always have to.
It's likely there's a permissions problem somewhere along the .rbenv path. You might try turning on write privileges for your user with:
$ chmod -R +w ~/.rbenv
That will recursively (-R) change the file mode (chmod) to write permission (+w) for all files and directories under your user's .rbenv path. There's no particular reason for not having files set to write.
For Mac M1 systems try,
Allowing full disk access to terminal.
Apple->systemPreferences->Security&Privacy->privacy(Tab)->'+' button, check in Terminal application.
Then Restart terminal
2.Try using,
sudo chflags noschg
Delete the pod folder, reinstall it again. If it doesn't work use this command:
sudo pod install --allow-root
It really doesn't matter on mac how you configure your eyaml create the dir and config manually, add some public key location to it, and its works just fine after adding full disk access to the terminal as Kewin suggested ^ ^. Thumbs up.
No need to change permission, just export GEM_HOME:
export GEM_HOME="$HOME/.gem"
please run:
sudo gem install pg
I'm trying to install Prestissimo to an Ubuntu 16.04 server, but that leads to an error:
$ composer global require "hirak/prestissimo:^0.3"
Changed current directory to /home/kramer65/.composer
[ErrorException]
file_put_contents(./composer.json): failed to open stream: Permission denied
require [--dev] [--prefer-source] [--prefer-dist] [--no-progress] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--] [<packages>]...
I'm logged in as user kramer65, so I wouldn't know why it can't write to my home folder. My normal reaction to a permission denied is to use sudo, but composer then always says:
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Any idea how I can solve this?
I had this problem to install laravel/lumen.
It can be resolved with the following command:
$ sudo chown -R "$(id -un)" "$(composer config --global home)"
What this command does: Execute as privileged user (root) the command to change file owner (not group) to the current user (by name) recursively to the COMPOSER_HOME directory.
As the user-name as well as the composer home directory can be different on each system, the following two commands are in use to obtain the ...
... username: id -un
... composer home directory: composer config --global home
This is an old question, and so a reader of the answer may want to become aware of the following:
Prestissimo was dedicated to be used with Composer 1
As of today, Composer 2 has been released which already didn't benefit from Prestissimo any longer.
But even further as of today, Composer 2.2 has been released which is a Long Term Support (LTS) version you should replace Composer 1 with immediatly if you deemed it to require Presstissimo in the past as it is in general and overall much more faster than Composer 1 ever was - with or without Prestissimo.
How to continue:
Remove Prestissmo from any of your systems.
Replace Composer 1 with Composer 2.2 on any of your systems.
Enjoy.
To resolve this, you should open up a terminal window and type this command:
sudo chown -R user ~/.composer (with user being your current user, in your case, kramer65)
After you have ran this command, you should have permission to run your composer global require command.
You may also need to remove the .composer file from the current directory, to do this open up a terminal window and type this command:
sudo rm -rf .composer
For me, in Ubuntu 18.04. I needed to chown inside ~/.config/composer/
E.g.
sudo chown -R $USER ~/.config/composer
Then global commands work.
In my case I don't have issues with ~/.composer.
So being inside Laravel app root folder, I did sudo chown -R $USER composer.lock and it was helpful.
I faced this issue as well but in my case, I was in wrong directory. Check the directory you are working
In my case, .composer was owned by root, so I did sudo rm -fr .composer and then my global require worked.
Be warned! You don't wanna use that command if you are not sure what you are doing.
In my case all the permissions were correct at all the locations manetioned in other answers here, but I was still getting this error.
Turned out there were some vendor directories that were owned by root. Composer writes composer.lock files all over the place when it's doing an update or install.
So solving my case - and this is specifically for a laravel sail container - all ownerships were switched to user sail in the project:
Enter the sail container as root:
vendor/bin/sail root-shell
Set the file ownership for all files in the project:
chown -R sail:sail /var/www/html
You may just want to do the vendor directory only as a first try:
chown -R sail:sail /var/www/html/vendor
The ownership was wrong after switching from a hand-rolled docker-compose.yaml setup to Laravel Sail, which IMO handles file ownership and permissions in a sensible way, separating root from the application user sail.
This might be super edge case, but if you are using Travis CI and taking advantage of caching, you might want to clear all cache and retry.
Fixed my issue when I was going from sudo to non sudo builds.
I was getting the same exception, but in my case I am using PowerShell to run commands
So, I fixed this with an instruction to unblock multiple files first.
PS C:\> dir C:\executable_file_Path\*PowerShell* | Unblock-File
and then use the following to load the package
& 'C:\path_to_executable\php.exe' "c:\path_to_composer_.phar_file\composer.phar "require desired/package
I was getting the same error when using it with WSL Windows 10. I used the following command to solve it:-
sudo chown -R $USER /home/<username>/.config/composer
I had same issue in windows version of composer that has installed in
C:\composer
When I was trying this command
C:\composer require aws/aws-sdk-php
then simply I got into composer installed folder and try it again
C:\composer>composer require aws/aws-sdk-php
the package installed quickly .
In my case I used sudo mkdir projectFolder to create folder. It was owned by root user and I was logged in using non root user.
So I changed the folder permission using command sudo chown mynonrootuser:mynonrootuser projectFolder and then it worked fine.
I was facing the same issue when I was running the composer require inside /var/www/html ,the default root folder of the apache web server and I was able to solve it by making the current user the owner of this html directory by
sudo chown -R $USER /var/www/html
But you definitely want to set the permissions
chmod 755 -R /var/www/html
There are 2 components to consider.
Composer wants you to run it as the logged in user. However, your webserver wants to have permissions over your application.
The solution is to add your user to the webserver group, then update the permissions of your application.
For Ubuntu running Apache webserver, use the following command to add yourself to the Apache group, replacing <username> with your username
sudo usermod -a -G www-data <username>
Now you need to update your permissions on your application. Navigate to the root folder of your application and use the following command
sudo chown -R $USER:www-data .
Composer now has the necessary permissions to pull in the packages you need and Apache has the necessary permissions to deliver your application.
I Install Vagrant in my Ubuntu(14.4) System. When i Enter Vagrant Up comment Display following Errors.
/opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/machine_index.rb:321:in `initialize': Permission denied # rb_sysopen - /home/w3cert/.vagrant.d/data/machine-index/index.lock (Errno::EACCES)
Permission denied
means that the file /home/w3cert/.vagrant.d/data/machine-index/index.lock is owned by another user and your current user has no permission.
check who is the owner of your file, if you run any install/command with sudo or root then your current user will not have access to modify the file.
for now you can change the ownership of all .vagrant.d files to your account and you should be able to run the vagrant up command
i had the same problem. I used Vagrant before and uninstall it. When i tried to reinstall back i had the same error
My solution was to delete the .vagrant.d temp folder (in your case /home/w3cert/.vagrant.d/)
Hope it works for you as well
As Manuel stated, deleting the .vagrant.d folder will solve the issue.
oddly this happened on windows as well, i didn't install anything new, or reinstall vagrant or anything like that. the only thing i can think of is the power cut we had last week has caused a folder/file lock... although a reboot should solve that :S
So on my linux AWS instance, I am trying to install a laravel application and am running into an awful amount of permission problems.
By default, when I cloned my project into var/www/, the owner was Root. I changed the owner to apache, and added ec2-user to apache. From what I've read, this seems correct.
From there, I tried to run php composer.phar install, which resulted in a permissions error unless I ran it sudo, and then the error was that "Class 'PDO' not found in /var/www/Mumble/app/config/database.php".
So from there, it looked like PDO wasn't installed, so I used yum to install it, which got me the typical laravel error log, but it is now saying "could not find driver". Looking at php info, pdo is configured for mysqli. Could that be my problem? Does anybody know of some places I could look for resources?
First things first, the latest version of laravel is 4.3, compatible with PHP >= 5.4 (Source: Laravel Installation).
The bad news is, the yum package of apache on AWS comes with PHP 5.3. Check your php version using php phpinfo() in your ssh console.
If you have the proper PHP version, you will have to make sure PHP is running underneath the user apache.
Go to /etc/php.ini and search for the parameter user=. Make sure it says user=apache, and group=apache.
If all of this checks out, your final step is to make sure that your /app/storage directories are on a 777 permission with owner being apache. Only laravel uses these for internal purposes, so it's alright.
I suspect you need to give the permission to access, is it accessible the /var/www directory?
if not try this,
sudo chmod -R 777 /var/www
for secure permission use 775 for the directories.
perhaps permission you need to set:
# Set group to www-data
sudo chgrp www-data /var/www
# Make it writable for the group
sudo chmod 775 /var/www
# Set GID to www-data for all sub-folders
sudo chmod g+s /var/www
# Add your username to www-data group
sudo usermod -a -G www-data username
# Finally change ownership to username
sudo chown username /var/www/
# Your account shouldn't have any more permission issues
Note: please read about the file permission before you go further .
When I instal nextgen-gallery plugins. This error message appears
Downloading update from https://downloads.wordpress.org/plugin/nextgen-gallery.zip…
Unpacking the update…
Could not create directory.
How can I fix this problem ?
This is a permissions issue. Ensure the directory is writable by apache. Plugins are unpacked into the wp-content/plugins directory, so I would first attempt writing to the directory as apache:
sudo -u apache touch /path/to/wp-content/plugins/test.txt
Set permissions accordingly to correct the issue. You can read about permissions here: https://www.pluralsight.com/blog/it-ops/linux-file-permissions
You can read about the correct file permission scheme for Wordpress here: https://wordpress.org/support/article/changing-file-permissions/
#skrilled and #knutole's answer was great but I found that when attempting to fix the issue on the plugins folder, everything was ok and the answer did not work for me.
If anyone else has this issue, try looking at the upgrades folder also. This folder (from what I can see) is used as a folder to store temporary files for when WP upgrades or plugin updates are being ran.
If you simply receive the message stating 'Could not create directory' and there is no path specified, it could actually be talking about the upgrades folder.
Most likely, if you have configured it correctly, the http server associated to your wordpress site belongs to the group www-data. That's how one should configure it correctly.
Try members www-data and ps aux | grep www-data to be sure. In the latter command you should see on the last columns either nginx or apache.
In this case, you just need to set that group to the directory
sudo chgrp -R www-data <your_wordpress_root_dir>/
and then add full group permissions to such directory
sudo chmod -R g+rwx <your_wordpress_root_dir>/
Now it works perfectly :)
for nginx people
if you have php-fpm installed you have to tell it that its user and group is nginx. /etc/php-fpm.d/www.conf . find user which is assigned to apache by default and change it to nginx. also do it for group. then run this command :
sudo service php-fpm restart
also inside of your wordpress directory execute these commands
sudo chown nginx:nginx * -R
sudo usermod -a -G nginx username
change username into what your current username is.
yet you have to apply propper permissions.
run these commands inside your wordpress directory
sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
If you are using vsftpd as your FTP server and have enabled passive connections, you need to add pasv_promiscuous=YES to /etc/vsftpd/vsftpd.conf.
I was having a similar issue. It started with me trying to update a plugin on a migrated WP install. I didn't get it, all my permissions were EXACTLY the same as the old server. In my situation, I started to see that not much was working properly. I couldn't install/delete plugins or themes as well as uploading media would error out. Then I found the fix via some research.
If you are still having this issue, and changing permissions DID NOT fix the problem try this:
Go in to your hosting control panel and find your hosting settings, wherever you can edit your scripting settings. In Plesk (as in my example), this would be under Websites & Domains. Click on your domain name at the bottom. On the next screen, where it says "PHP support (run as..." change the dropdown from "Apache module" over to "FastCGI application". Everything should be fixed up now!
(Re)setting the permissions via ftp didn't make a difference for me either. There is no SSH available, so I had to log in the control panel (directadmin in my case), the File Manager where I could "Reset Owner" to "File ownership reset" the /wp-contents directory.
I'm running Nginx with Wordpress. I deleted the upgrade folder in wp-content and then ran the upgrade from the wordpress GUI again. I noted the linux user for the upgrade folder created was www-data. I then did a {sudo chmod -R www-data:www-data .} Ran the upgrade again from the GUI and it worked.
Probably need to change the permissions on most of the folders so they can't be modified by www-data but I'll figure that out tomorrow.
A permission issue, make sure apache (www-data) has write permissions.
All the above is great, but I think you missed the simplest issue. Your website is using more space than it has allotted, and therefore it is broke. Wordpress makes more files as is in use. If you are on the margin of going over, a simple overnight issue where you did nothing is possible. Go to bed, everything fine. In the morning website is broke.
I own my websites so I go into the reseller part of Hostmonster or Hostgator (I have sites on both hosting platforms) and I reallocate more space and the problem goes away usually. Try that first, or look into it before messing around with permissions. If you changed a permission and the issue came up, could be permissions, otherwise, check this first.
I had the same issue when I tried to install wp plugin(s). However, I managed to solve the problem with the following command:
sudo wp plugin install [plugin name] --allow-root