I am having issues with writing to the target folder of a symlink. The files can be read without any issues, but as soon as I try to upload something to the target folder I get a write permission error.
lrwxrwxrwx. 1 user1 user1 47 Mar 17 12:35 data -> /home/user2/public_html/apps/public/data/
The target folder has 0777 permissions and is owned by user2
drwxrwsrwx. 135 user2 user2 12288 Mar 16 10:18 .
What am I missing, why can't I write files/folders to the symlink target? I am running WHM/Cpanel on CentOS if that makes any difference. Cheers!
Most linux systems require a user's home directory to have 700 perms.
user1 can't access user2's home directory or anything below it.
You should move these directories somewhere other than a user's home dir if you want multiple users to have access...i.e. /opt/ or /var/
Related
I am trying to migrate a WordPress site using the Duplicator plugin. I have created an ec2 instance on AWS, installed Apache and copied over the files from the Duplicator backup to /var/www/html/.
When I visit the site on the browser going to myip/dup-installer/main.installer.php I get the following error:
My www folder permissions are : drwxrwxrwx 3 root www-data 4096.
My html folder permissions are: drwxrwxrwx 7 www-data www-data 4096.
My dup-installer folder permissions are: drwxrwxrwx 8 www-data www-data 4096.
And finally, my main.installer.php file permissions are: -rw-rw-r-- 1 www-data www-data 20437.
It all looks correct but I don't understand why I'm getting the error when I visit the installer. Is there something wrong with my permissions?
Currently, your permissions are fully open on your www directory. That shouldn't be like that, most files should not be world writable.
you should change this to 755 via this command:
sudo chmod -R 755 /var/www
Note, use the correct path to your www directory if it isn't correct for you.
regarding your missing CSRF (Cross-Site Request Forgery) file, this is probably because your copy didn't have the correct priv to copy it. Might look on the original server to see if you can grab it and move it over.
It turns out I had to execute [website-hush-information]_installer-backup.php which sits one level before the dup-installer folder.
I was trying to execute the main.installer.php inside dup-installer based on previous experience with this plugin, but in this version, this was not needed.
Thanks for the help #JP-LISN, it pointed me in to the correct direction by the process of elimination.
I've ran into a problem after setting a folder and its contents to 755 permissions.
I ran
chmod 755 -R folder/
However, when trying to access in my /var/www folder via the browser I get a 403 Forbidden error.
I did download the folder from the web, but other files with 755 permissions are loaded just fine into the browser. Here is what it looks like:
ls -l
drwxr-xr-x. 4 root root 4096 folder
Edit: If you're going to down vote, how about explain why?
drwxr-xr-x.
The trailing dot means the directory has an SElinux ACL, which is likely the cause of your problem. -- the ACL denies access.
I am trying to upload pictures in WordPress but I get this error:
The uploaded file could not be moved to wp-content/uploads.
I am running it in localhost but the answers I have found are to change the folder permissions to 777 on the server.
I tried making an uploads folder myself, but it's of no use and there is no option to change the folder permissions to anything except read and write.
I'm using XAMPP on Mac OS X; I'm new to WordPress - how can I fix this?
It is most likely a permissions issue. Find the user processes running on the site by navigating to your sites wp-content folder on the server your site is on. Then type this;
ps aux | egrep '(apache|httpd)'
Ignore root, but look at the other users
root 2507 0.0 0.3 423820 14328 ? Ss Aug04 0:51 /usr/sbin/httpd
apache 4653 0.5 1.9 483900 77252 ? S 16:27 0:14 /usr/sbin/httpd
apache 4654 0.5 2.1 500160 84912 ? S 16:27 0:13 /usr/sbin/httpd
apache 4656 0.8 2.0 484708 78712 ? S 16:27 0:21 /usr/sbin/httpd
...
For me it actually was apache (usually www-data). Finally change the users of the uploads folder to this user;
sudo chown -R apache:apache uploads
(make sure you are in the directory above the uploads folder when running this command)
This will permit the correct user to access this directory using the correct access permissions of 755.
By using the dreadful '777' advice of others, you are simply allowing the correct user to access the directory assigned to the incorrect user - as well as anyone else who can access that directory!
Provided that your wordpress directory is "owned" by the correct user, you should see your problem resolved if you set the permissions to 755.
Log on to your server, and cd to wp-content, then run:
chmod 755 uploads
I would recommend, for security's sake, instead of
sudo chmod 777 uploads
which gives permissions (read, write, execute) to the user who owns the folder (the root), to other users in the file's Group and to other users not in the file's group (anyone else).
sudo chmod 755 uploads
which gives all permissions to the owner, but only read and execute permissions to the other users
For anyone who has landed here but using a Windows / IIS platform then you can achieve the same thing by giving modify permissions to the Everyone group for your wp-content\uploads directory.
another possible reason is wrong owner and group of uploads folder.
try
chown -R _www:_www wp-content/uploads
assuming your apache group and owner is _www
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Say I have a folder "root". I own this folder, and I make it such that for others (which includes the user "user2", the permissions are r-x)
Within root I have another folder "bin". I change the owner of "bin" to the user "user2", and give him rwx permissions.
Will user2 be able to create new files in the folder "bin"? Does not having write for "root" affect his ability to do so?
Also, can user2 delete the entire folder "bin" from "root"? (I don't want him to be able to do so - he just needs to create/delete files within the folder bin!)
Yes. Because user2 has access (x) permission on root and owns bin, he can create files in root/bin. If the permissions do not currently include write permission for the owner, the owner (user2) can change the directory permissions so that the permissions do include write permission.
No. Because user2 does not have write permission in root, user2 cannot remove bin from root.
He can write inside of bin, but not outside of it. The scope of his rwx permissions resides within that folder unless you otherwise modify his permissions.
Understanding what you stated you have something like this:
drwxr-xr-x 10 root root 22 Dec 26 23:04 root
where the contents of "root" are like this:
cd root
ls -la
drwxr-xr-x 10 root root 22 Dec 26 23:04 .
drwxr-xr-x 29 root root 34 Oct 24 06:13 ..
drwx------ 2 user2 root 3 Oct 23 10:28 bin
The permissions on "root" have to be at least 555 (r-xr-xr-x) because it would not work if your "root" directory permissions were 500 or 550 (see below) because "user2" would not be allowed to enter the directory "root" (there are exceptions, like 550 would work if "user2" is member of the "root" group).
# This would not work, user2 cannot enter the "root" directory
drwx------ 10 root root 22 Dec 26 23:04 root
To understand all this security stuff you first have to realize that a directory is really, and simply, a file. The major difference between a directory and a file is the meaning of the "x" permission. If the user does not have "read" permission, he can't see the files in the directory. So, lets put the access to 711, like this:
drwx--x--x 10 root root 22 Dec 26 23:04 root
Now let's try to see what files are in the directory. You can't:
$ ls -la root
root: Permission denied
total 3
However, you can enter it (because of the "x" execute right) but you still can not see inside:
$ cd root
$ ls -la
.: Permission denied
total 3
But if you are aware that inside there exists a directory you have access to, you can enter it:
$ cd bin # Ps. Here we assume we did the 'cd root' above already
$ ls -la
total 6
drwxr-xr-x 2 user2 root 2 Mar 14 14:57 .
drwx--x--x 3 root root 3 Mar 14 14:57 ..
And "user2" can do, as the owner, anything he wants. The access to "bin" could even be "700", as long as you are the owner, you can enter it. Because the access is 755 (in our example), anyone can enter the directory "bin", but only "user2" can create files in it. Modifying or reading those possible files will depend on the access "user2" gives them.
"user2" cannot remove the "bin" directory, even if he owns it, because he does not own the "file" (i.e. the "root" directory) where the name of the "bin" directory is written. That is owned by the "root" user who is the only one allowed to write there.
When I try to install new modules to drupal 7 via "Install new module" form, I get following error message.
The specified file
temporary://fileTFJ015 could not be
copied, because the destination
directory is not properly configured.
This may be caused by a problem with
file or directory permissions. More
information is available in the
system log.
http://ftp.drupal.org/files/projects/date-7.x-1.0-alpha2.tar.gz
could not be saved to
temporary://update-cache/date-7.x-1.0-alpha2.tar.gz.
Unable to retrieve Drupal project
from
http://ftp.drupal.org/files/projects/date-7.x-1.0-alpha2.tar.gz.
My Drupal 7 is installed with CPanel QuickInstall tool and hosted with HostGator shared hosting service.
Any ideas how to solve this issue?
There is an issue with shared hosts and temp folders...if you want the background you can read this:
http://drupal.org/node/1008328
in the meantime try changing your tmp folder to be relative to your sites file root:
sites/default/files/temp
The quickest way to get a handle on this issue is to navigate via your web browser to:
/admin/config/media/file-system
You'll probably see an error there about not being able to write to the /tmp directory. To fix this, you can create a temp directory under site's root and set permissions appropriately.
1) Create a directory here [drupal_installed_here]/tmp
2) Navigate via your web browser to /admin/config/media/file-system and change the temp directory to be:
tmp instead of /tmp (no leading slash)
3) Try this command:
chmod 775 [drupal_istalled_here]/tmp
and refresh the /admin/config/media/file-system page
3) If that does not work, try this command:
chmod 777 /home/quickstart/websites/tmp
and refresh the /admin/config/media/file-system page
The last command opens up your temp directory permissions a lot (rwxrwxrwx), but sometimes that's necessary to get your site working on shared hosts.
This error took me a long time to figure out despite several threads on the internet related to it.
If you get this error on a page, then here are the steps that you need to follow to solve it:
Go to Admin->Reports->Recent Log Messages. Read the most recent error message. This will tell you which folder is causing the problem. It is not necessarily the directory listed in the online threads about this subject. For me it was: sites/default/files/js
If you are running Drupal on a linux server then you need to add read/write permissions to the problem folder. You can do this by going to the linux/SSH command line and typing the following (replace the folder address with the address for your folder)
chmod 777 /var/www/html/sites/default/files/js
That's it. The error message should be gone now.
My old, problematic configuration:
chmod 664 -R /var/drupal-bc/sites/default/files
chmod 664 -R /var/drupal-bc/sites/default/private
drw-rw-r-- 2 www-data www-data 4096 Jul 31 12:35 files
drw-rw-r-- 3 www-data www-data 4096 Jul 5 15:08 private
My new, functional configuration:
chmod 774 -R /var/drupal-bc/sites/default/files
chmod 774 -R /var/drupal-bc/sites/default/private
drwxrwxr-- 2 www-data www-data 4096 Jul 31 12:35 files
drwxrwxr-- 3 www-data www-data 4096 Jul 5 15:08 private
Please do not use 777 permissions, because you will have security problems. 775 will do just fine.
chmod 775 -R /var/drupal-bc/sites/default/files
chmod 775 -R /var/drupal-bc/sites/default/private
If you have javascript caching turned on, you might need to 755 the /sites/all/your-theme/js
chmod 777 /var/www/html/sites/default/files/js
solved the issue for me