I have some trouble installing some packages I compiled from source. Everything seems to work fine, until I try to actually use the files installed in a global place.

It turns out the permisions and users/groups of the newly created files are all messed up. It is very easy for me to replicate with a simple directory and file creation commands:

$ sudo mkdir /usr/local/bar
$ sudo touch /usr/local/bar/foo
$ ls -l /usr/local
total 11M
drwxr--r--  2 root root 4,0K jul 24 23:56 bar/
$ ls -l /usr/local/bar/
ls: cannot access '/usr/local/bar/foo': Permission denied
total 0
-????????? ? ? ? ?            ? foo
$ sudo ls -l /usr/local/bar/
total 0
-rw-r--r-- 1 root root 0 jul 24 23:56 foo

As seen by the example above, the created directory looks fine initially, but when looking inside it the user, group and everything else for the files is totally messed up. They do look fine when looking at it from the superuser perspective with sudo.

Using chown or chmod doesn't matter, as long as I use sudo whatever I do results in the same problem.

My /etc/sudoers file (without comments):

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

root    ALL=(ALL:ALL) ALL

%admin ALL=(ALL) ALL

%sudo   ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d

myusername  ALL=NOPASSWD: ALL

It should all be default, except for the last line which I added to not have to write the password every time.

I have a fully up-to-date 16.04 installation.

Could it be something wrong with my installation? Something wrong with sudo or how I use it? Anything else?

Output of umask -S as requested:

$ umask -S
$ sudo bash -c "umask -S"


$ grep '^UMASK\|^USERGROUPS_ENAB' /etc/login.defs
UMASK       033
  • Can you post the output of umask -S and sudo bash -c "umask -S" please? – Byte Commander Jul 24 '16 at 22:29
  • @ByteCommander Added. – Some programmer dude Jul 24 '16 at 22:33
  • There is the problem. Now I also need the output of grep '^UMASK\|^USERGROUPS_ENAB' /etc/login.defs please and I'll write an answer for you :) – Byte Commander Jul 24 '16 at 22:36
  • @ByteCommander Added that too. – Some programmer dude Jul 24 '16 at 22:38
  • 1
    And why did you change UMASK? Do you need the changes? Because the problem here is that you do not give execution permissions by default, but those are needed to browse a directory. Without that, you are not able to list new directories' contents. – Byte Commander Jul 24 '16 at 22:43

The problem on your system is that your umask settings are a bit strange/messed up.

For general information about umask please refer to What is "umask" and how does it work?
In short we can say that the umask defines the default permission set for new files. It is configured in /etc/login.defs.

The default value for umask is 022 which results in default permissions for new files to be rwxr-xr-x (owner: full access, group: read/execute, world: read/execute).

You have changed this setting to 033 which results in default permissions to be rwxr--r--, i.e. no execute permissions for group and others.

The problem we're facing here when removing execute permissions from a directory is that it becomes no longer browsable. You need the execute permission to list a directory's contents. Because the newly generated directories have execution for everybody but their owner declined, only the owner user (here root) can list the directory contents by default.

You have two options:

  • Keep the umask and manually add execution permissions for others using chmod +x on all directories where you need them.

    This is a lot of work and you will likely forget it every now and then. Only do this if you have a good reason for a non-default umask.

  • Reset the umask back to its default 022.

    To do this, open the file /etc/login.defs with your favourite text editor as root, e.g. using sudo nano /etc/login.defs.

    Search for this line:

    UNAME       033

    And replace it with the default settings again:

    UNAME       022

Additionally I have also seen that you have USERGROUPS_ENAB set to no, but its default is yes. This setting does not only make the umask group permissions equal to the owner permissions for non-root users, but also causes automatic generation (and deletion, if no longer needed) of users' primary groups (same name and ID as user).

I would personally recommend to reset that line to its defaults as well, unless you have a reason not to do that.

Therefore search the line


and replace it with

| improve this answer | |
  • I added a paragraph because I'm a bit confused why you have set USERGROUPS_ENAB no. I would personally recommend to reset it back to "yes", but that is not directly related with the problem described in the question. – Byte Commander Jul 24 '16 at 23:01

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.