I have a strange issue on my debian vm.
I have a nginx directory like that.
$ ll
total 9076
-rw-r----- 1 www-data adm 330645 juil. 13 10:40 access.log
-rw-r--r-- 1 www-data root 143902 juil. 12 01:08 access.log.1
-rw-r----- 1 www-data adm 852976 juil. 13 10:41 error.log
I try to read the access.log with the foo user.
So, I have added this user to adm group.
$ cat /etc/group | grep adm
adm:x:4:admin,foo
But the user can't read the file. I have tried to add the user to www-data group, but the problem is the same. Do you know what is the problem ?
I thought know how user/group works, it seems not :)
BR,
Eric
To read a file, the user needs execute privileges to all of the parent directories. If your logs are in /var/log/nginx make sure the foo user or one of its groups has x access to each directory (/var, /var/log/, /var/log/nginx) of whatever path logs are in.
Related
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/
I created a user with admin access named hadoop. The funny thing is that when I create a folder and try to give it 777 access it gives me back an error.
hadoop#linux:~$ mkdir testfolder
hadoop#linux:~$ ls -ltra testfolder/
total 8
drwxrwxrwx 25 hadoop sudo 4096 Jun 14 20:00 ..
drwxrwxr-x 2 hadoop hadoop 4096 Jun 14 20:00 .
hadoop#linux:~$ chmod -777 -R
testfolder/ chmod: cannot read directory ‘testfolder/’: Permission denied
Why is that when I am the creator of the directory ?
hadoop#linux:~$ groups
hadoop root sudo
Strangely, using the GUI, I can go in and right click the directory and change the file permissions. Can anyone help me understand what i am not understanding.
Note : I use Ubuntu 14
Your command chmod -777 -R testfolder/ is the issue here, more specific the - as part of the first argument.
Leave it away, just use chmod 777 -R testfolder/ and all should be fine...
Not exactly sure about the details, but the -777 should remove permissions, thus preventing access at least to the recursive portion of the command. I assume that is not what you want to do. Instead you probably want to grant more permissions to the directory. Looks like the command blocks itself. Though that might be by purpose, at least in an indirect manner.
I am working on Solaris 10 machine. In that i cannot able to untar my file. Logs are given below. Anyone please suggest what may be the issue? I can able to create tar file but unable to untar. :(
bash-3.2# ls -lrth ConfigCheck-120614-KL.out*
-rw-r--r-- 1 root root 144K Jun 12 17:15 ConfigCheck-120614-KL.out
-rwxrwxrwx 1 root root 146K Jun 16 16:49 ConfigCheck-120614-KL.out.tar
bash-3.2# tar xvf ConfigCheck-120614-KL.out.tar
tar: extract not authorized
bash-3.2# tar tvf ConfigCheck-120614-KL.out.tar
-rw-r--r-- 0/0 147377 Jun 12 17:15 2014 ConfigCheck-120614-KL.out
Solaris 11 tar will fail with that error message if you are running as uid 0 but do not have the Media Restore profile set up in the RBAC configuration.
Unless you're trying to restore from backup, you should normally be untarring files as a normal user, not root, to avoid accidentally overwriting critical system files.
I keep seeing a 403 error for my stylesheet which is hosted on my Rasberry Pi (webserver). I ran ls -al and this is the result:
pi#raspberrypi ~/www $ ls -al
total 16
drwxr-xr-x 2 pi root 4096 Mar 17 20:18 .
drwxr-xr-x 12 root root 4096 Mar 15 16:44 ..
-rw-r--r-- 1 pi root 644 Mar 17 20:18 index.html
-rw------- 1 pi root 329 Mar 17 20:19 stylesheet.css
The index.html data shows up when I point my browser at the ip, but there is no formatting and whenever I try to acess the css file through looking at the source code it keeps telling me theres a 403 error :(
Can anyone help a brother out??
Cheers!
You need proper permissions for the www folder, and that depends on which webserver you are running. For apache on debian the user is www-data, if your webroot is ~/www and you are user pi try these commands
Change owner to apache user recursively
Change Permissions to read for all recursively
chown -R www-data:www-data /home/pi/www
chmod -R 644 /home/pi/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.