I have to set an environment variable called GDK_NATIVE_WINDOWS to fix the problem with Eclipse buttons in Ubuntu. To set the environment variable, I added the following line to ~/.pam_environment.


Surprisingly, the environment variable doesn't get set when I echo $GDK_NATIVE_WINDOWS in a terminal. However, all other environment variables that I've listed in ~/.pam_environment are set properly. Besides, when I switch to a tty, e.g. Alt+Ctrl+F1, the environment variable gets set correctly. What's wrong with setting this environment variable in ~/.pam_environment?

  • 1
    did you restart your X session? Apr 12, 2010 at 17:24
  • Yes, I restarted my X session by logging out and in, and even restarting the machine. Apr 14, 2010 at 0:41

6 Answers 6


Stick to the simple "key=value" syntax in the ~/.pam_environment file. No DEFAULT, OVERRIDE, ${HOME}, no nothing. Just key=value. The man page you linked to is for pam_env.conf, only. See "man 8 pam_env" which does not promise anything else "This module can also parse a file with simple KEY=VAL pairs on separate lines.".

By the way putting something like PATH=${PATH}:more/paths in ./pam_environment is a great way to break almost any attempt to login, since the PATH gets set to ${PATH}:more/paths literally (not much to be found there). To rescue, "/bin/mv .pam_environment out_of_the_way" and re-login.

  • But system software (e.g. Ubuntu MATE and Cinnamon, e.g. 20.04 LTS) changes the content of file ~/.pam_environment with lines such as LC_TIME DEFAULT=en_DK.UTF-8, suggesting it is valid. Are they in error? Jun 4, 2020 at 19:19
  • @PeterMortensen It is conceivable that my answer from 2013 does not accurately describe the situation in 2020. Jun 4, 2020 at 20:36
  • It was always wrong. $HOME/.pam_environment is not like /etc/environment. man 7 pam_env. Aug 29, 2022 at 15:32

As you have identified, your environment variables should be set in ~/.pam_environment as recommended on https://help.ubuntu.com/community/EnvironmentVariables. Easier said than done ;)

It is possible that you ran into the same configuration gap that existed for me. See the workaround for encrypted home below.

My ~/.pam_environment:

PATH            DEFAULT=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:${HOME}/bin
IDEA_JDK        DEFAULT=${HOME}/Applications/jdk

Why the ugly static path? ${PATH} would not work for me. I bricked my login several times trying to work around it so I am sticking with the ugly static copy of the defaults :)

Workaround for encrypted home folders

In Ubuntu releases up to and including Ubuntu 12.04 (Precise Pangolin) Beta 2, if you are using an encrypted home directory you will need to modify /etc/pam.d/common-session to get it to load ~/.pam_environment. This solution apparently works for earlier releases, but I have not tested it.

Guenther Montag (g-montag) wrote on 2010-08-19:

This seems to be an issue with encrypted home directories. I added

session required pam_env.so

at the end of /etc/pam.d/common-session and now ~/.pam_environment gets read. On another system without encrypted home directories (also 10.04) the work around is not needed. Perhaps in my case the system tries to read ~/.pam_environment before it is decrypted.

  • 1
    My home folder is not encrypted. Apr 5, 2012 at 4:26
  • Seems $HOME/.pam_environment was broken around ubuntu 13. That might be why Alain the settings worked for Alain. Aug 29, 2022 at 15:35

You have a space in between GDK_NATIVE_WINDOWS and DEFAULT=true . This differs from the example you linked.




I think that's because when you start a terminal you are not launching a login session. It's a terminal session, and it works with different rules.

I never really got the difference and the need to differentiate, but in any case I suggest you to use ~/.bash_profile and/or ~/.bashrc to achieve the same result, unless you have been suggested to use pam for specific reasons.


In Debian bullseye (probably way back to around 2013) and ubuntu back to at least 14.04 (tested in a docker container), ~/.pam_environment is not read per user_endir defaults to off for pam_env (see man 7 pam_env). If you want to reenable it:

echo 'session optional pam_env.so user_readenv=1' >> /etc/pam.d/common-session

that is, set for an interactive session (CLI or graphical logins, like su) the pam_env with user_reader at 1.

I believe it was disabled upstream due to:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708 " The pam_env module in Linux-PAM (aka pam) 1.1.2 and earlier reads the .pam_environment file in a user's home directory, which might allow local users to run programs with an unintended environment by executing a program that relies on the pam_env PAM check. "

Thought the above description is not clear to me. If it means that ~/.pam_environment allows to change the program environment without the user knowing then any option n the home folder is alike (ie ~/.profile, ~/.zprofile). Mind ~/.profile is told to be read by graphical login managers ... so why remove ~/.pam_environment and keep ~/.profile?

A proper way would be to have the capability to set environment variables per user in /etc/security/pam_env.conf. Not yet requested upstream though. Or any option editable only with admin rights.


It looks like it's just a bug that my environment variable is not being set.

  • 3
    It's not a bug. That's not a valid syntax for ~/.pam_environment. See manpages.ubuntu.com/manpages/hardy/man5/pam_env.conf.5.html
    – Gili
    Jul 13, 2012 at 18:25
  • 1
    @Gili My example matches the syntax VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]] at the link you posted. Note that I'm using ${} rather than @{} to refer to HOME and PATH because they are environment variables. Jul 14, 2012 at 18:58
  • Not likely a bug, something else probably overrides it later, like your X profile as it works with just a shell. The VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]] syntax is valid for ~/.pam_environment. ${HOME} and ${PATH} are empty at this point because it runs so early, but you can set them here. @{HOME} refers to the home as specified in /etc/passwd. Note that environment variables (and @{HOME} and @{SHELL}) are not expanded in the name=value syntax, you have to use name DEFAULT=value [OVERRIDE=val2] for that.
    – TwoD
    Sep 26, 2018 at 21:20
  • False. The VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]] syntax is the $HOME/.pam_environment syntax (see man 7 pam_env user_envfile). Also, even the /etc/environment syntax does not work in $HOME/.pam_environment. There is a bug and telling otherwise is confusing people and lead to it never getting fixed. And it is plain wrong. Aug 29, 2022 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .