1

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?

Aditya
  • 13,416

3 Answers3

3

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/null you are reading from ./testfile and writing to /dev/ (to supplant /dev/null). This is what mv does when you try to move a file to a file.

A quick stat testfile /dev/null /dev/ will show you:

  File: ‘testfile’
  Size: 7944        Blocks: 16         IO Block: 4096   regular file
Device: fc01h/64513d    Inode: 5284807     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     oli)   Gid: ( 1000/     oli)
Access: 2014-03-19 11:35:42.027427288 +0000
Modify: 2014-03-19 12:25:17.343476867 +0000
Change: 2014-03-19 12:25:17.343476867 +0000
 Birth: -

File: ‘/dev/null’ Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 5h/5d Inode: 31128501 Links: 1 Device type: 1,3 Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2014-03-18 14:33:16.742165089 +0000 Modify: 2014-03-18 14:33:16.742165089 +0000 Change: 2014-03-18 14:33:16.742165089 +0000 Birth: -

File: ‘/dev/’ Size: 4740 Blocks: 0 IO Block: 4096 directory Device: 5h/5d Inode: 1025 Links: 17 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2014-03-20 09:51:04.408762425 +0000 Modify: 2014-03-20 09:51:04.396762425 +0000 Change: 2014-03-20 09:51:04.396762425 +0000 Birth: -

  • You have read access to ./testfile
  • You have write access into the /dev/null pseudo character device.
  • You don't have permission to write into /dev/ (which you would need to replace /dev/null)
  • Permission denied.

The second example is much easier to read. From your output:

drwx------  2 root   root    4096 Mar 11 21:04 .gvfs
drwx------  2 root   root    4096 Mar 11 21:04 dconf

These directories are owned by root and they give no permission for anybody else to read or enter them. find just bounces off because it doesn't have permission to enter.

Oli
  • 293,335
1

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 nano to open a directory called .gvfs. Unless you are root (via sudo) 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 user root has read, write and execute permissions on that directory.

How do we know only root has 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 root and the group attributes are also root as can be seen by the root root bit. Therefore, only the root user has any permission to do anything with .gvfs. Any other user that is a member of the root group 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 group root has 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 root has the permission to run the command or only root has 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.

RobC76
  • 121
  • 3
1

Is there any general guideline to follow in order to know "why" I get a Permission Denied error while running a particular command?

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:

 find /home/ -uid 0

(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 to find /home/ -type d -uid 0 (-type f for just files).

As to this example:

drwx------  2 root   root    4096 Mar 11 21:04 .gvfs
drwx------  2 root   root    4096 Mar 11 21:04 dconf

your command, in this case, should have included sudo to prevent the message since those 2 are not owned by your username and both the group and others are excluded from r(ead). So ...

sudo find . -inum 393222 -exec nano {} \;

But the notice about the permission itself is harmless. You can even suppress error messages by adding 2>/dev/null to 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 rm or mv, /dev/null, /dev/random and things like forkbombs (not giving examples of those :) ).

Rinzwind
  • 299,756