I've been working on *nix for a few years now, and one of the things I just can't get used to is octal permissions in code. Is there some other reason than line length to prefer chmod 644 ... over chmod u=rw,go=r ...?

PS: I'm not looking for an explanation of octal permissions. I know how they work, and it's well explained in the manual. I'm asking why octal seems to be preferred over the more human-readable form.


Using the octal codes has two advantages I can think of, neither of which is that huge:

  1. They're shorter, easier to type.
  2. A few things only understand them, and if you routinely use them you'll not be scratching your head (or running to documentation) when you run into one. E.g., you have to use octal for chmod in Perl or C.

Sometimes really simple utilities won't handle the "friendly" versions; especially in non-GNU userlands.

Further, some utilities spit out octal. For example, if you run umask to see what your current umask is, it'll spit it out in octal (though in bash, umask -S does symbolic).

So, in short, I'd say the only reason to prefer them is to type fewer characters, but that even if you elect not to use them, you should know how they map so that you can figure out an octal code if you run into one of the things that only does octal. But you don't need to immediately know that 5 maps to rx, you only need to be able to figure that out.

  • 1
    Saying that chmod in Perl or C needs to use octal representation isn't really an advantage seeing as the representation already existed in the first place. – n0pe Dec 12 '11 at 17:22
  • @MaxMackie: Its an advantage to you using them. I shall clarify. – derobert Dec 12 '11 at 17:28

Guess I've been using octal for too long.

7 is rwx (do anything with it), 5 is rx (gotta read it to execute it), 6 is wr (any data file you need to modify), 4 is r (we'll let you look at it), and 0 is - (sorry, nothing here to see). And the order is Me, Us, Everyone. These are the basic combinations.

755 I can change and run it, everyone else can run it.

644 I can change it, everyone else can read it.

444 Read only for everyone, we're through here.

500 I can execute it, don't want it to change, everyone else hands off.

For me, it's short, to the point. 9 characters and a file spec and move on.

  • Well, octal (base-8), not hex (base-16). – derobert Dec 12 '11 at 17:03
  • Yep, that one, the half a hex. <grin> – Fiasco Labs Dec 12 '11 at 17:07
  • Same here, I find the octal easier to read than the text version... – Brian Knoblauch Dec 16 '13 at 21:22

I've never really enjoyed the octal representation, I've always gone for straight up rwxr-xr-x notation as it seems simpler to me. However, from what I gather octal representation exists to actually make it easier for us to remember (I don't see how that works).

The only other possible benefit I see octal bringing to the table is a lack of ambiguity. The 8 different permission bit configurations are represented by a single distinct number, which I'm sure helps some people accidentally put a w where they shouldn't have.

Unfortunately though, I have memorized this table:

#  r  w  x
0  0  0  0
1  0  0  1
2  0  1  0
3  0  1  1
4  1  0  0
5  1  0  1
6  1  1  0
7  1  1  1
  • 8
    I learned it as using binary for each set of 3. so rw------- would be (110)(000)(000), which is (6)(0)(0). rwxr-xr-x would be (111)(101)(101), so (7)(5)(5). – Rob Dec 12 '11 at 16:10
  • 4
    The primary reason the octal representation exists is because that's how the original Unix permission system was programmed, from C. 4 octal digits (remember the special ones, like 1777 for /tmp, including the sticky bit) takes 12 bits, a convenient size on PDPs, especially the PDP-8. If they'd gone with hex, a natural mapping of one permission set per hex digit would have required a 16-bit+ word machine, which not all PDPs were. It would also have wasted 3 bits or required that they invent a use for those bits, which probably would have complicated Unix perms with no real benefit. – Warren Young Aug 29 '12 at 18:19
  • ⁺¹ goes to @Rob btw. Indeed, after that calculating an actual number from the binary representation is a basic combinatorics, and you don't even need to remember about having "octal" because the maximum number (i.e. 111b ) won't exceed 7. – Hi-Angel Oct 13 '17 at 14:32
  • This table make it very clear. That's great!!! – Little Roys Aug 29 '18 at 3:02

I think the reason is again - history. At first the octal values were the only ones. The symbolic ones came later.

I prefer the symbolic ones. Especially if you do want to change existing values without touching other portions.

Like chmod -R u=rwx,g-w+X,o=- do that in octal...


Note that octal modes may remove setuid and setgid bits on some systems.

Fedora 16:

$ mkdir dir
$ chmod 2775 dir
$ stat -c %a dir
$ chmod 770 dir
$ stat -c %a dir

(the 2 is preserved)

FreeBSD 9:

$ mkdir dir
$ chmod 2775 dir
$ stat -f %Mp%Lp dir
$ chmod 770 dir
$ stat -f %Mp%Lp dir

(the 2 became a 0)

If you want to change a file or directory's permissions, it can be better to just specify the bits you want to change (e.g. chmod o= dir or chmod o-rwx dir in the above example).


History explains why the octal modes exist, but I think functionality is the reason why the mnemonic form exists. And all the points about other tools using exclusively octal modes are perfectly valid and I think you have to learn and know them. Nevertheless I find that conservative admins don't see the true utility that comes from the mnemonic form.

The octal form, especially when used recursively, tends to force admins to do stupid things. Or rather added negligence results in it turning out stupid. Whenever you run across some folder with a lot of text files and the x bit set, you have proof.

Why would anyone set the x bit like that? Because it's difficult not to unless you use the mnemonic form for modes. Consider that you want to reset the permissions on /var/www and you don't run any old-style CGI, so the x bit should be removed. However, the x bit serves another purpose on directories. So you end up doing something (as root) like:

chmod -R 666 /var/www
find /var/www -type d -exec chmod 777 {} \;

If, however, you were using the mnemonic form you could give it a "recipe":

chmod -R a=rwX /var/www

which is the short form of chmod -R ugo=rwX /var/www (achieving the same, but different path: chmod -R a-x,a+rwX /var/www).

But there is another thing that is more trivial which can't be achieved with the octal modes. You cannot adjust the user or group or other mask individually with the octal form.

In short: it's like comparing a scalpel (mnemonic) and a sharp kitchen knife (octal) ... but you still have to know the octal mode bits for other reasons :)

The reason why octal modes are still preferred, I think, is not more typing involved in the mnemonic form, but overly conservative admins. And yes, 2013 calling, those overly conservative admins still exist and are here to stay for some time.


When you have to modify the permissions of files all the time, you appreciate the 3 characters. A lot of the time I use the + or - versions to change permissions.

For example, I create a new PHP, Python or other script in my apache folder. chmod a+x is all I do so it can be run. I read it as "all plus execute". Now I know it's going to work, and I only needed 3 characters.

Other times I use 644 and 755 automatically. I just think of it as 644 means a file, 755 means a script.


It nicely fits to the umask settings, which are usually given in octal writing (in pam or fstab).


I suggest that one important reason is that the octal representation matches closely what you see with ls -l (or, rather, it does when you mentally convert between octal and binary).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.