I had recently tried to move a file to overwrite /dev/null and had encountered a Permission denied Error. From using Ubuntu for the last couple of years, I know that if I get this error, I need to be sudo to invoke the command and then it would succeed. This is what I did to overwrite /dev/null as well.
However, artbristol posted a comment over there saying that blindly invoking sudo to run a command is not a good habit and we should know why we are being denied the permission to run that command before proceeding further. I tend to agree with him along with all the people who have heavily upvoted that comment. But I don't know how to proceed to know the "why".
Recently, I came across this answer and tried to run the command as mentioned (393222 is the inode of examples.desktop file in ~):
$ find . -inum 393222 -exec nano {} \;
find: `./.gvfs': Permission denied
find: `./.cache/dconf': Permission denied
Running the above command did open examples.desktop file in nano, but also gave Permission denied for the two folders. Following are the attributes of the two folders (truncated output of ls -la):
drwx------ 2 root root 4096 Mar 11 21:04 .gvfs
drwx------ 2 root root 4096 Mar 11 21:04 dconf
Is there any general guideline to follow in order to know "why" I get a Permission Denied error while running a particular command?
You have to use your brain a little and ask yourself the question:
What is the application actually trying to do?
There isn't going to be a single answer to this as "Permission denied" errors transcend filesystems, networks and authentication regimes (to name just three)... There's just no single way to find the problem... Other than to say, "you probably don't have permission to do what you're doing".
But we can look at your examples and work out where the problem is in those.
In
mv testfile /dev/nullyou are reading from./testfileand writing to/dev/(to supplant/dev/null). This is whatmvdoes when you try to move a file to a file.A quick
stat testfile /dev/null /dev/will show you:./testfileThe second example is much easier to read. From your output:
These directories are owned by root and they give no permission for anybody else to read or enter them.
findjust bounces off because it doesn't have permission to enter.It all depends on what the command is doing. The list is very long. Let's take your example from above.
You're trying to use
nanoto open a directory called .gvfs. Unless you areroot(viasudo) then you won't be able to.Why?
Look at the file permissions on the left.
The first character is
d. This means .gvfs is a directory. Opening a directory in a text editor isn't going to do you much good but it's possible all the same.The next three characters are
rwx. R=read, W=write & X=execute. This means that the userroothas read, write and execute permissions on that directory.How do we know only
roothas these permissions?Generally there are 10 characters that you can see for a file permission. In this case they are
drwx------.After the first character the permissions are read in blocks of 3. The first 3 are owner permissions, the next 3 are group permissions and the final 3 are world permissions.
So, the directory, as we can see, is owned by user
rootand the group attributes are alsorootas can be seen by theroot rootbit. Therefore, only therootuser has any permission to do anything with .gvfs. Any other user that is a member of therootgroup doesn't have any permissions - as can be seen with the second block of 3 file permissions:---. The same goes for any other user regardless of their group membership as can be seen with the third block of 3 file permisisons:---.If .gvfs has permissions of
drwxrw-r--, the following will apply:rwx= the owner (root) of the directory has read, write & execute permissions on this directory.rw-= any user in the grouproothas read, write permissions but no execute permission.r--= any other user has read only permission. No write or execute permissions.Whenever you get a Permission Denied error you need to know what it is you, or the command you are executing, is trying to do.
Sometimes only
roothas the permission to run the command or onlyroothas the permission to carry out the instructions the command you are running as a different user is trying to do - such as editing a system configuration file.I hope this hasn't confused you even more.
The general idea is that those directories are not owned by the user you used to search with and it is also not in the group. So the command informs you it can not enter that directory to perform your find. Inside /home there are some files not belonging to the user.
You can use this:
(or a similar command:
ls -la| awk '{ if ($3 == "root") print $9}') to find all files in /home owned by root. Files it self will not give an error with find, just directories so you could expand that tofind /home/ -type d -uid 0(-type ffor just files).As to this example:
your command, in this case, should have included
sudoto prevent the message since those 2 are not owned by your username and both the group and others are excluded from r(ead). So ...But the notice about the permission itself is harmless. You can even suppress error messages by adding
2>/dev/nullto your find.And yes, we will all agree that any command needs to be examined up front. There are some common things to look for though: like
rmormv,/dev/null,/dev/randomand things like forkbombs (not giving examples of those :) ).