Trying to upload a file with opening new folder.
But laravel returns error like below.
$destinationPath = public_path() . $folderName;
if(!is_dir(public_path().'/uploads')) {
mkdir(public_path().'/uploads', 0755, true);
}
$mkdir = mkdir(public_path().'/uploads/'.$unique, 0755, true);
$success = file_put_contents(public_path().'/uploads/'.$unique."/".$filename, $file);
I used;
sudo chown -R nginx:nginx public/uploads
sudo chown -R root:root public/uploads
sudo chown -R $USER:$USER public/uploads
But nothing changed.
What's wrong?
Is laravel's nginx user different? How can I learn?
you should check the Nginx user inside your Nginx config file.it can be found at /etc/nginx/nginx.conf and likely set to user www-data;
Try running the command
sudo chown -R www-data:www-data public/uploads
This command should work. If now let me know.
Related
I'm running WordPress 5.8.1 on localhost, on my Mac. I am unable to update plugins. I get this error:
Update failed: Could not create directory.
I've tried changing the permission on the wp-content folder as suggested here like this:
sudo chmod -R 755 wp-content
but it didn't work. I still get the error message.
I also tried this
sudo chown -R _www wp-dir
sudo chmod -R g+w wp-dir
still no luck.
Ok, Managed to find the issue. Apache uses a different username so this command was ok:
sudo chown -R _www wp-dir
But my username wasn't _www (hence my error)
you can find the apache username in the etc/httpd.conf file
please can anyone help with a solution? am getting an error message that says permission denied anytime I try to upload files to my (LEMP) server using File Zila. I have tried changing the file permission in File Zilla to 777 but still does not work.
if you have SFTP then follow below steps:
sudo chmod -R o+rw /var/www/html /* Location for folder or file */
chmod -R 755 /var/www/html/ /* Location for folder or file */
If you are trying to give the {user} as well as the www-data both access to the website directory try this
//without {}
sudo usermod -a -G www-data {userName}
#This adds user to www-data group
//set permissions for user group www-data
sudo chgrp -R www-data /var/www/html
//followed by
sudo chmod -R g+w /var/www/html
this will enable {user} to use SFTP with the FileZilla or other programs to read and write files in the directory without sudo
I can't get my nginx working, I am getting permission denied.
Tried:
sudo chmod o+x /home
sudo chmod o+x /home/path-to-www
sudo chown -R nginx:nginx /home/path-to-www/www
sudo chmod -R 755 /home/path-to-www/www/
service nginx restart
The above did not work.
So I tried:
sudo chown -R path-to-www:path-to-www /home/path-to-www/www
plus:
setting the nginx user to path-to-www and retarting again.
This didn't work as well.
I am out of ideas. Anyone?
Solved: It was Selinux. I disabled it and rebooted and it worked.
I am trying to upload an image to set a background image for my theme, but I get this error:
Unable to create directory wp-content/uploads/2018/05. Is its parent directory writable by the server?”
I tried to change the access permissions with the help of these blogs:
https://www.digitalocean.com/community/questions/setting-permissions-for-wordpress
https://gist.github.com/Adirael/3383404
But nothing has helped me, and now I also get a 500 error page.
I'm stuck here, can anybody help?
-----------Comment-----------
Output Image for ps -ef| grep httpd
I executed this command
find . type f -exec chmod 644 {} \;
and the 500 error page is not being displayed now. I am able to view my web page. But I am still unable to upload a background image. (same error appears "Unable to create directory wp-content/uploads/2018/05. Is its parent directory writable by the server?")
The following command will fix your issue
sudo chmod -R 777 wp-contents/uploads/
If you're using Bitnami Lamp then run the following commands in your SSH terminal:
sudo chown -R bitnami:daemon /opt/bitnami/apache/htdocs
sudo chmod -R g+w /opt/bitnami/apache/htdocs
sudo chmod 440 /opt/bitnami/apache/htdocs/wp-config.php
sudo chmod 440 /opt/bitnami/apache/htdocs/.htaccess
and if you're using Bitnami WordPress then run the following commands in your SSH terminal:
sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs
sudo chmod -R g+w /opt/bitnami/apps/wordpress/htdocs
sudo chmod 440 /opt/bitnami/apps/wordpress/htdocs/wp-config.php
sudo chmod 440 /opt/bitnami/apps/wordpress/htdocs/.htaccess
The recommended permissions are:
Directories: 775
Files: 640
wp-config.php and.htacess: 440
Thanks
Maybe is already solved, but can help other users with similar issues.
I made a Shell Script on Debian10 to solve permissions issues.
After running it, I make the folder accesible on the Apache2.conf too (WordPress can't Upgrade or Upload Media if not)
What it does:
Set new Owner on all Files and (Sub)Directories ( user:group )
Set Permissions: 755 to Directories and 644 to Files
wp-config.php : Preventing world access for "wp-config.php", leaving it accesible to WordPress (660)
Allow WordPress to manage the "wp-content" (Directories to 755 & Files to 664)
Privatize "wp-content" (Set 755)
Link:
https://github.com/ieselisra/wordpress_fix_permissions_debian10/
I'm setting up Tomcat on Centos according to https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-8-on-centos-7 , but with a twist: I put Tomcat in /opt/apache-tomcat-8.5.6 and then set up a symbolic link:
sudo ln -s /opt/apache-tomcat-8.5.6 /opt/tomcat
Now I change the group ownership of /opt/tomcat to tomcat:
sudo chgrp -R tomcat /opt/tomcat/conf
Then I give the tomcat group write access to the configuration directory:
sudo chmod g+rwx /opt/tomcat/conf
But here is the problem: I try to give the tomcat group read access to all the configuration files:
sudo chmod g+r /opt/tomcat/conf/*
That gives me an error: chmod: cannot access ‘/opt/tomcat/conf/*’: No such file or directory
What? Does chmod not accept wildcards? Or does it not look inside symbolic links? What's going on?
Note that I got around it by doing this:
sudo chmod g+r -R /opt/tomcat/conf
Does that give me effectively the same thing? (I know that it additionally makes the directory readable by the group, but that seems inconsequential --- the group could already read the directory.) Why doesn't the wildcard version work?
Globs are expanded by the current shell. This happens before sudo and chown are ever invoked.
If the current shell doesn't have access to list the files, the glob will be treated as unmatched and just left alone. This makes chmod try to access a file literally named *, which fails.
root# echo /root/.*
/root/.bash_history /root/.bashrc ...
user$ sudo echo /root/.*
/root/.*
The same is true for command substitution, process substitution and other expansions, which are similarly unaffected by sudo:
root# echo $(whoami)
root
user$ sudo echo $(whoami)
user
The shell is also responsible for pipes and redirects, which are also set up before sudo ever runs:
root# echo 60 > /proc/sys/vm/swappiness
(command exits successfully)
user$ sudo echo 60 > /proc/sys/vm/swappiness
bash: /proc/sys/vm/swappiness: Permission denied
In Unix terms, sudo is wrapper for execve(2), and therefore can't help with anything that you can't do through an execve call. If you need shell functionality from the target user, you need to manually invoke that shell:
user$ sudo sh -c 'chmod g+r /opt/tomcat/conf/*'