Noob here: I have a problem, when i access my server via SSH, the $PATH is correct

root@ks391320:~# echo $PATH

But when i open my server via XRDP session and go to the terminal it shows an incorrect PATH:

root@ks391320:~# echo $PATH

Screenshot of both: Screenshot

And this creates an issue because when I try to install something using the "Package Installer" it shows this error (among others)

dpkg: warning: 'ldconfig' not found in PATH

8 Answers 8


For Ubuntu-18.04, edit /etc/pam.d/xrdp-sesman and enter the following lines at beginning:

session       required   pam_env.so readenv=1 envfile=/etc/environment
session       required   pam_env.so readenv=1 envfile=/etc/default/locale
  • Yes, without this, xrdp sessions were missing all the variables defined in my /etc/environment !
    – wisbucky
    Apr 18, 2019 at 17:28


The system-wide default PATH is defined in /etc/environment. First, verify that it's set to a sane value. For reference, here's mine, which is the same as a default install:



If /etc/environment is sane and you're still having issues, you can override the default PATH in ~/.bashrc. For example, I have this in my .bashrc which appends a directory to my PATH if and only if it exists and is not already in my PATH:

if [ -d "$HOME/bin" ]; then
    if [[ $PATH =~ $HOME/bin ]]; then :
    else export PATH="$HOME/bin:$PATH"

Since it appears from your screenshot that you've enabled root logins, be sure to set root's .bashrc, as well. (By the way, since root can't login by default in Ubuntu, this configuration is presumably less tested and might possibly be related to your problem.)


If the first two methods fail, then check whether your XRDP client is doing something exotic. If so, you'll have to either configure it to work normally or identify a way to work around it.


I've been doing some looking around the system. You can find all the places on your system that specify a PATH with the following command (the sudo is there because some files under /etc are unreadable by normal users):

sudo egrep -nr '\bPATH' /etc | less

I think it's safe to ignore many of those places, resulting in the following command:

sudo egrep -nr '\bPATH' /etc | egrep -v '^/etc/(init|rc|ppp|bash_c)' | egrep -v '^Binary' | less

One file that looks possible (though I really don't know too much about it) is /etc/login.defs. You might take a look at it.

In addition, you could grep your dotfiles as well:

egrep -nr '\bPATH' $HOME/.* | less
  • The "environment" file is normal, adding the correct paths to ~/.bashrc makes the commands run on the terminal but still not working on the Ubuntu "Package Installer". I couldn't find the root of the problem but i have a solution now, i created a symbolic link in /bin/ to each program required (ldconfig, etc)... this is probably a security breach so i will leave this question open in case anyone haves a better solution. Jan 3, 2012 at 22:03
  • @IvanCastellanos: I'm not sure what you mean by "package installer," as there's no program with that exact name AFAIK. Could you describe the steps you're taking to install packages? And is this a GUI or command-line installer? Jan 3, 2012 at 23:23
  • Sorry, i mean "GDebi Packpage Installer" (GUI). Jan 4, 2012 at 4:45
  • @IvanCastellanos: Do you launch it as gksudo gdebi-gtk /full/path/to/package.deb? I've found it to be a bit picky. If so, then it should inherit the environment it's launched from. Jan 4, 2012 at 5:49

Full disclosure: I don't use Ubuntu... but I had the same issue with Debian.

xrdp launches /etc/xrdp/startwm.sh (unless Ubuntu has modified this location). I added this line:

. /etc/profile

to the top of /etc/xrdp/startwm.sh and the PATH is now set correctly.

For Ubuntu, adding

. /etc/environment

to the top of /etc/xrdp/startwm.sh might do the same.

  • interesting that /etc/profile is called twice in /etc/xrdp/startwm.sh while ~/.profile is not called at all. I added it at the end. Also interesting that this seems to be a pending issue since over 10 years Jan 30, 2023 at 16:25

This stumped me for a while too. /etc/environment isn't a shell script, so you can't call it as one. What worked for me was to edit the xrdp session manager "sesman" script in pam. I added the "session" line to my /etc/pam.d/sesman file:

session required pam_env.so readenv=1 user_readenv=0
@include common-auth
@include common-account
@include common-session
@include common-password

This makes the session manager load the /etc/environment file at login.


In theory adding

. /etc/environment

would work but it doesn't. I just put it at the top of my .bashrc to correct the problem


Thanks to the previous answers I came to such a solution:

cat /etc/xrdp/startwm.sh | sed "s/. \/etc\/X11\/Xsession/. \/etc\/environment/" > ./startwm.sh && echo ". /etc/X11/Xsession" >> ./startwm.sh && sudo mv ./startwm.sh /etc/xrdp/startwm.sh && sudo chmod 755 /etc/xrdp/startwm.sh

May be not the most optimal but working (Ubuntu 12.04).


@ John: I believe you need to check your /etc/xrdpstartwm.sh - the first lines in mine reads,

if [ -f /etc/X11/xinit/xinitrc ]
    . /etc/X11/xinit/xinitrc
    exit 0

That means that if /etc/X11xinit/xinitrc exists, that file will be executed instead - and it won't help much to add the

. /etc/environment

to /etc/xrdpstartwm.sh. :-)

/Per Hertz


Member of the xrdp packaging team here.

The just-uploaded xrdp_0.9.17-2.dsc (Debian sid) fixes this via the PAM configuration, after independent discovery by me, then confirmation from an xrdp project member.

The applied fix is:

$ cat /etc/pam.d/xrdp-sesman 
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
@include common-account
@include common-session
@include common-password

Therefore, the locale workaround could be removed, so that…

$ cat /etc/xrdp/startwm.sh 
# xrdp X session start script (c) 2015, 2017, 2021 mirabilos
# published under The MirOS Licence

# Rely on /etc/pam.d/xrdp-sesman using pam_env to load both
# /etc/environment and /etc/default/locale to initialise the
# locale and the user environment properly.

if test -r /etc/profile; then
    . /etc/profile

test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession

… is left properly in the wm startup file.

You must log in to answer this question.

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