In the past, I have always set umask at ~/.profile. I set a umask of 077 so my documents get a permission of 600 (rw-------). But setting this at ~/.profile no longer works in Ubuntu 17.04.

So as new documents get created in a gnome session on Ubuntu 17.04, where can I configure so that they get created with permission 600?


To set permissions for all directories and files that are created day-forward by any user:

  1. sudo nano /etc/pam.d/common-session
  2. Find the line with "session optional pam_umask.so"
  3. Change this to "session optional pam_umask.so umask=0077"
  4. Save the file.
  5. Reboot.

New files will be 600. New directories will be 700.

| improve this answer | |
  • Except for the bug in the default GNOME terminal linked to in Daniel's answer, this works, but I'm curious why you're suggesting modifying /etc/pam.d/common-session directly, given that the value is primarily defined in /etc/login.defs (at least as of 18.04 - has that changed)? – mklement0 May 10 '19 at 15:24
  • 1
    @mklement0 Probably because of the comment in the default .profile: "for setting the umask for ssh logins, install and configure the libpam-umask package" – Redsandro Jul 14 '19 at 2:11

Ubuntu 18.04, should work for 17.04 and others

According to the man pages, there are several places where we can set the umask for the PAM module to find; it even gives an example. I'll set it in /etc/pam.d/login. Note this file does not exist on my version of Ubuntu, in which case we can create it.

$ sudo sh -c "echo 'session optional pam_umask.so umask=0027' >> /etc/default/login"

$ more /etc/default/login
session optional pam_umask.so umask=0027

Evil Bug

Now if we restart and ask for the umask in the terminal we still get 0022 and not the 0027 that was set. See Bug #1685754.

But if we open an application, for example the Text Editor, and save a file we'll notice the new umask is set correctly. Open it from the menu, not from the terminal as it seems to pick up the (bad) umask from the terminal.

$ touch terminal-file
$ ls -l
-rw-r-----  1 daniel daniel    0 jan 28 21:21 gedit-file
-rw-r--r--  1 daniel daniel    0 jan 28 21:22 terminal-file


| improve this answer | |
  • Good to know about the bug. Is there a reason you're not modifying the UMASK value directly in the preexisting /etc/login.defs file (or does that work differently in 17.04)? Also, you mention /etc/pam.d/login in the text, but your command modifies /etc/default/login. – mklement0 May 10 '19 at 15:20

If you're using GDM, it doesn't read ~/.profile like LightDM does. And the terminal normally opens a non-login shell. The net effect is that ~/.profile is not loaded at all when you open a terminal after logging in using GDM.


  • put your settings in ~/.bashrc, or
  • set your terminal to start a login shell, or
  • switch to LightDM
| improve this answer | |
  • Actually I just confirmed his issue on a freshly installed 17.04 version. Has nothing to do with GDM since by default lightDM is still used. – Ziazis Jun 28 '17 at 8:56
  • OK, so? Did I say his issue doesn't exist? – muru Jun 28 '17 at 8:57
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

That's literally what your ~/.profile says. Did you relogin once changed? It should work fine.


This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login exists.

Actually confirmed the issue on a freshly installed ubuntu 17.04. Even fully updating still causes this issue to arise and even ~/.bash_profileis ignored, there seems to be an issue with the command interpreter not reading those files after login.

You can use ~/.bashrc for now, which still works fine and is read during login.

So after digging a little into it, it seems bash is not run by default with the --login anymore which means it doesn't read the ~/.profile. Starting a new bash with the umask in ~/.profile with bash --login sets the umask correctly starting a bash without it though ignores the ~/.profile. Not sure what was changed but this seems like a bug to me unless it was intentionally changed.

| improve this answer | |
  • Yes, I relogged in. – G.W. Jun 27 '17 at 14:47
  • And the only ~/.bash files I have are .bashrc, .bash_logout, .bash_history. I ran a find search. .bash_profile and .bash_login do NOT exist on machine. – G.W. Jun 27 '17 at 16:31
  • Oh, I'm sorry you are actually right. I just freshly installed a 17.04 to test it on a new installation and it actually isn't read from ~/.profile for some reason. I haven't digged into it yet. But you can add your umask into ~/.bashrc for now this is still read during startup. – Ziazis Jun 28 '17 at 8:36
  • Ziazis, setting umask in .bashrc only works for docs created in terminal. I'm looking to get umask applied for example from doc created in gedit. You have found a fix with bash -login? How do I implement this exactly? Or is this unfixable until a bug is fixed? – G.W. Jun 28 '17 at 14:42

On Ubuntu 18.04.3 I have tried to create /etc/default/login with session optional pam_umask.so umask=0027 as Daniel says but not worked for me, instead I have changed the umask in /etc/login.defs and it worked.

I have changed umask value in 002 and now all the users create files with full permission also for their own group.

| improve this answer | |

I have the workaround at least on Fedora 31:

sudo vi /etc/profile.d/umask.sh
umask <your_umask>

sudo vi /etc/login.defs
UMASK <your_umask>

sudo vi /usr/local/bin/systemd-user
/usr/lib/systemd/systemd --user

sudo chmod a+x /usr/local/bin/systemd-user

sudo vi /usr/lib/systemd/system/user@.service
| improve this answer | |

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.