This section will cover the configuration of GDM and the format of the configuration file. However you can use the gdmsetup binary to configure GDM from a graphical environment. The configuration program does not however let you configure every aspect of GDM however, so if the setup program does not cover your needs you may find information in this section.

The configuration files, and especially the gdm.conf file, contain lots of useful comments, so also read these when changing your setup.

Some keys in the configuration file as shipped are commented out while others are set. This is done so that defaults can be easily changed in the future for some keys. If you wish to set such a key you must first remove the leading hash mark that marks it as a comment.

The configuration files for GDM are located in the <etc>/gdm/ directory. And some which can be shared among other display managers are located in the <etc>/dm/ directory.

This is a listing of the config directory contents:


gdm.conf is the main GDM configuration file. The options will be described later in this section. factory-gdm.conf is the configuration file as shipped with the daemon. This can be useful if you wish to revert to the default configuration.

locale.alias is a file which looks much like the system locale alias but in fact it is not the same. These are the languages that are available on your system. All the languages are still tested to see if they actually exist before presenting them to the user.

Xsession is a script which sets up a user session and then executes the users choice of session.

XKeepsCrashing is a script which gets run when the X server keeps crashing and we cannot recover. The shipped default script will work with most Linux distributions and can run the X configuration program provided the person on the console knows the root password.

gdm.conf is configuration file for both gdm, gdmgreeter, gdmlogin, and gdmchooser since a lot of parameters overlap.

Accessibility modules are configured in the modules/ subdirectory, and are a separate topic. Read the default files provided, they have adequate documentation. Again normally the default install is given in the files with factory in their name, and those files are not read, they are just there for you so you can always revert to default config.

The remaining configuration is done by dropping scripts in the subdirectories of the <etc>/gdm/ folder or dropping .desktop-style files in /etc/X11/sessions/. The latter is also read by KDM for common configuration. Next the directory <share>/gdm/BuiltInSessions/ is read for GDM specific built in sessions (KDM hardcodes these at time of this writing). Also the default setup will also read <share>/xsessions/ (which should be /usr/share/xsessions/ if you really wish to cooperate with KDM) where desktop packages can install their session files. The directories under the /etc should be reserved for configuration. This approach makes it easy for package management systems to install window managers and different session types without requiring the sysadmin to edit files. See the SessionDesktopDir configuration key for changing the paths. It used to be that GDM stored its built in sessions in <etc>/dm/Sessions/ but this is now deprecated as of Note that prior to version only the <etc>/dm/Sessions/ was being read.

A session can be disabled (if it was installed in /usr/share/xsessions/) by adding an identically named .desktop to one of the directories earlier in the path (likely /etc/X11/sessions) and using Hidden=true in that file.

The Script Directories

In this section we will explain the Init, PostLogin, PreSession and PostSession directories as they are very similar.

When the X server has been successfully started, GDM will try to run the script called Init/<displayname>. I.e. Init/:0 for the first local display. If this file is not found, GDM will attempt to to run Init/<hostname>. I.e. Init/somehost. If this still is not found, GDM will try Init/XDMCP for all XDMCP logins or Init/Flexi for all on demand flexible servers. If none of the above were found, GDM will run Init/Default. The script will be run as root and GDM blocks until it terminates. Use the Init/* script for programs that are supposed to run alongside with the GDM login window. xconsole for instance. Commands to set the background etc. goes in this file too.

It is up to the sysadmin to decide whether clients started by the Init script should be killed before starting the user session. This is controlled with the KillInitClients option in gdm.conf.

When the user has been successfully authenticated GDM tries the scripts in the PostLogin directory in the same manner as for the Init directory. This is done before any session setup is done, and so this would be the script where you might setup the home directory if you need to (though you should use the pam_mount module if you can for this). You have the $USER and $DISPLAY environment variables set for this script, and again it is run as root. The script should return 0 on success as otherwise the user won't be logged in. This is not true for failsafe session however.

After the user session has been setup from the GDM side of things, GDM will run the scripts in the PreSession directory, again in the same manner as the Init directory. Use this script for local session management or accounting stuff. The $USER environment variable contains the login of the authenticated user and $DISPLAY is set to the current display. The script should return 0 on success. Any other value will cause GDM to terminate the current login process. This is not true for failsafe sessions however. Also $X_SERVERS environmental variable is set and this points to a fake generated x servers file for use with the sessreg accounting program.

After this the base Xsession script is run with the selected session executable as the first argument. This is run as the user, and really this is the user session. The available session executables are taken from the Exec= line in the .desktop files in the path specified by SessionDesktopDir. Usually this path is /etc/X11/sessions/:<etc>/dm/Sessions:/usr/share/xsessions/. The first found file is used. The user either picks from these sessions or GDM will look inside the file ~/.dmrc for the stored preference.

This script should really load the users profile and generally do all the voodoo that is needed to launch a session. Since many systems reset the language selections done by GDM, GDM will also set the $GDM_LANG variable to the selected language. You can use this to reset the language environmental variables after you run the users profile. If the user elected to use the system language, then $GDM_LANG is not set.

When the user terminates his session, the PostSession script will be run. Again operation is similar to Init, PostLogin and PreSession. Again the script will be run with root privileges, the slave daemon will block and the $USER environment variable will contain the name of the user who just logged out and $DISPLAY will be set to the display the user used, however note that the X server for this display may already be dead and so you shouldn't try to access it. Also $X_SERVERS environmental variable is set and this points to a fake generated x servers file for use with the sessreg accounting program.

Note that the PostSession script will be run even when the display fails to respond due to an I/O error or similar. Thus, there is no guarantee that X applications will work during script execution.

Except for the Xsession script all of these scripts will also have the environment variable $RUNNING_UNDER_GDM set to yes, so that you could perhaps use similar scripts for different display managers. The Xsession will always have the $GDMSESSION set to the basename of the session that the user chose to run without the .desktop extension. In addition $DESKTOP_SESSION is also set to the same value and in fact this will also be set by KDM in future versions.

Neither of the Init, PostLogin, PreSession or PostSession scripts are necessary and can be left out. The Xsession script is however required as well as at least one session .desktop file.

The Configuration File - gdm.conf

The daemon and the accompanying utilities share a common configuration file: <etc>/gdm/gdm.conf.

The configuration file is divided into sections each containing variables that define the behavior for a specific part of the GDM suite. The file is fairly well commented as well.

gdm.conf follows the standard .ini style configuration file syntax. Keywords in brackets define sections, strings before an equal sign (=) are variables and the data after equal sign represents their value. Empty lines or lines starting with the hash mark (#) are ignored. The graphical configurator will try to preserve both comments (lines with a hash mark) and the overall structure of the file so you can intermix using the GUI or hand editing the configuration file.

Daemon Configuration



If true, then enables gdmgreeter/gdmlogin to be launched with additional Gtk+ modules. This is useful when extra features are required such as accessible login. Note that only "trusted" modules should be used to minimize security issues.

Usually this is used for accessibility modules. The modules which are loaded are specified with the GtkModulesList key.


If true, then gdm never tries to reuse existing X servers by reinitializing them. It will just kill the existing server and start over. Normally, just reinitializing is a nicer way to go but if the X server memory usage keeps growing this may be a safer option.


If the user given in AutomaticLogin should be logged in upon first bootup. No password will be asked. This is useful for single user workstations where local console security is not an issue. Also could be useful for public terminals, although there see TimedLogin.


This user should be automatically logged in on first bootup. AutomaticLoginEnable must be true and this must be a valid user for this to happen. "root" can never be autologged in however and gdm will just refuse to do it even if you set it up.

The following control chars are recognized within the specified name:

%% — the `%' character

%d — display's name

%h — display's hostname

Alternatively, the name may end with a vertical bar |, the pipe symbol. The name is then used as a program to execute which returns the desired username on standard output. If an empty or otherwise invalid username is returned, automatic login is not performed. This feature is typically used when several remote displays are used as internet kiosks, with a specific user to automatically login for each display.


This is the base X session file. When a user logs in, this script will be run with the selected session as the first argument. The selected session will be the Exec= from the .desktop file of the session.

If you wish to use the same script for several different display managers, and wish to have some of the script run only for GDM, then you can check the presence of the GDMSESSION environmental variable. This will always be set to the basename of .desktop (without the extension) file that is being used for this session, and will only be set for GDM sessions. Previously some scripts were checking for GDM_LANG, but that is only set when the user picks a non-system default language.

This script should take care of doing the "login" for the user and so it should source the /etc/profile and friends. The standard script shipped with GDM sources the files in this order: /etc/profile then ~/.profile then /etc/xprofile and finally ~/.xprofile. Note that different distributions may change this however. Sometimes users personal setup will be in ~/.bash_profile, however broken that is.


Full path and name of the chooser executable followed by optional arguments.

Configurator=<bin>/gdmsetup --disable-sound --disable-crash-dialog

The pathname to the configurator binary. If the greeter ConfigAvailable option is set to true then run this binary when somebody chooses Configuration from the Actions menu. Of course GDM will first ask for root password however. And it will never allow this to happen from a remote display.


These are the languages that the console cannot handle because of font issues. Here we mean the text console, not X. This is only used when there are errors to report and we cannot start X.


Specifies the path which will be set in the user's session.


The session that is used by default if the user does not have a saved preference and has picked 'Last' from the list of sessions. Note that 'Last' need not be displayed, see the ShowLastSession key.


Directory containing the display init scripts. See the ``The Script Directories'' section for more info.


If true then the last login information is printed to the user before being prompted for password. While this gives away some info on what users are on a system, it on the other hand should give the user an idea of when they logged in and if it doesn't seem kosher to them, they can just abort the login and contact the sysadmin (avoids running malicious startup scripts). This was added in version

This is for making GDM conformant to CSC-STD-002-85, although that is purely theoretical now. Someone should read that spec and ensure that this actually conforms (in addition to other places in GDM). See for more info.


If true, GDM will warn the user if they are already logged in on another virtual terminal. On systems where GDM supports checking the X virtual terminals, GDM will let the user switch to the previous login virtual terminal instead of logging in.


An X command line in case we can't start the normal X server. should probably be some sort of a script that runs an appropriate low resolution server that will just work. This is tried before the XKeepsCrashing script is run.


On systems where GDM supports automatic VT (virtual terminal) allocation, this is the first vt to try. Usually standard text logins are run on the lower vts. See also VTAllocation.


The maximum number of allowed flexible servers. These are servers that can be run using the /tmp/.gdm_socket socket connection. This is used for both full servers and for Xnest servers.


After how many minutes of inactivity at the login screen should a flexi server be reaped. This is only in effect before a user logs in. Also it does not affect the Xnest flexiservers. To turn off this behaviour set this value to 0. This was added in version


Full path and name of the greeter executable followed by optional arguments. This is the greeter used for all servers except for the XDMCP remote servers. See also RemoteGreeter


The group name under which gdmlogin, gdmgreeter, gdmchooser and the internal failsafe GTK+ dialogs are run. Also see User. This user will have access to all the X authorization files, and perhaps to other internal GDM data and it should not therefore be a user such as nobody, but rather a dedicated user. The ServAuthDir is owned by this group. The ownership and permissions of ServAuthDir should be root.gdm and 1770.


A colon separated list of Gtk+ modules that gdmgreeter/gdmlogin will be invoked with if AddGtkModules is true. The format is the same as the standard Gtk+ module interface.

HaltCommand=/sbin/shutdown -h now

Full path and arguments to command to be executed when user selects Shutdown from the Actions menu. This can be a ';' separated list of commands to try. If a value is missing, the shutdown command is not available. Note that the default for this value is not empty so to disable shutdown you must set this explicitly to an empty value.


Determines whether GDM should kill X clients started by the init scripts when the user logs in.


Directory containing the log files for the individual displays. By default this is the same as the ServAuthDir.


Name of the file containing the gdm process id.


Directory containing the scripts run right after the user logs in, but before any session setup is done. See the ``The Script Directories'' section for more info.


Directory containing the scripts run after the user logs out. See the ``The Script Directories'' section for more info.


Directory containing the scripts run before the user logs in. See the ``The Script Directories'' section for more info.

RebootCommand=/sbin/shutdown -r now

Full path and optional arguments to the program to be executed when user selects Reboot from the Actions menu. This can be a ';' separated list of commands to try. If missing, the reboot command is not available. Note that the default for this value is not empty so to disable reboot you must set this explicitly to an empty value.


Full path and name of the greeter executable followed by optional arguments. This is used for all remote XDMCP sessions. It is useful to have the less graphically demanding greeter here if you use the Graphical Greeter for your main greeter. See also the Greeter key.


Specifies the path which will be set in the root's session and the {Init,PostLogin,PreSession,PostSession} scripts executed by GDM.


Directory containing the X authentication files for the individual displays. Should be owned by root.gdm with permissions 1770, where gdm is the GDM group as defined by the Group option. That is should be owned by root, with gdm group having full write permissions and the directory should be sticky and others should have no permission to the directory. This way the gdm user can't remove files owned by root in that directory, while still being able to write its own files there. GDM will attempt to change permissions for you when it's first run if the permissions are not the above. This directory is also used for other private files that the daemon needs to store. Other users should not have any way to get into this directory and read/change it's contents. Anybody who can read this directory can connect to any display on this machine.


Directory containing the .desktop files which are the available sessions on the system. Since this is treated like a PATH type variable and the first file found is used.


Program to use when playing a sound. Currently used for playing the login sound, see the SoundOnLoginFile key. Supported since


Full path and arguments to the standard X server command. This is used when gdm cannot find any other definition, and it's used as the default and failsafe fallback in a number of places. This should be able to run some sort of X server.


Full path and arguments to command to be executed when user selects Suspend from the Actions menu. If empty there is no such menu item. Note that the default for this value is not empty so to disable suspend you must set this explicitly to an empty value.


If the user given in TimedLogin should be logged in after a number of seconds (set with TimedLoginDelay) of inactivity on the login screen. This is useful for public access terminals or perhaps even home use. If the user uses the keyboard or browses the menus, the timeout will be reset to TimedLoginDelay or 30 seconds, whichever is higher. Note that no password will be asked for this user so you should be careful.


This is the user that should be logged in after a specified number of seconds of inactivity. This can never be "root" and gdm will refuse to log in root this way. The same features as for AutomaticLogin are supported. The same control chars and piping to a program are supported.


This is the delay before the TimedLogin user will be logged in. It must be greater then or equal to 10.


The username under which gdmlogin, gdmgreeter, gdmchooser and the internal failsafe GTK+ dialogs are run. Also see Group. This user will have access to all the X authorization files, and perhaps to other internal GDM data and it should not therefore be a user such as nobody, but rather a dedicated user.


The directory where user's .Xauthority file should be saved. When nothing is specified the user's home directory is used. This is tilde expanded so you can set it to things like: ~/authdir/.

If you do not use the tilde expansion, then the filename created will be random, like in UserAuthFBDir. This way many users can have the same authentication directory. For example you might want to set this to /tmp when user has the home directory on NFS, since you really don't want cookie files to go over the wire. The users should really have write privilages to this directory, and this directory should really be sticky and all that, just like the /tmp directory.

Normally if this is the users home directory GDM will still refuse to put cookies there if it thinks it is NFS (by testing root-squashing). This can be changed by setting NeverPlaceCookiesOnNFS in the [security] section to false.


If GDM fails to update the user's .Xauthority file a fallback cookie is created in this directory.


Name of the file used for storing user cookies.


On systems where GDM supports automatic VT (virtual terminal) allocation (currently Linux and FreeBSD only), you can have GDM automatically append the vt argument to the X server executable. This way races that come up from each X server managing it's own vt allocation can be avoided. See also FirstVT.


A script to run in case X keeps crashing. This is for running An X configuration or whatever else to make the X configuration work. See the script that came with the distribution for an example. The distributed XKeepsCrashing script is tested on Red Hat, but may work elsewhere. Your system integrator should make sure this script is up to date for your particular system.

In case FailsafeXServer is setup, that will be tried first. and this only used as a backup if even that server keeps crashing.


The full path and arguments to the Xnest command. This is used for the flexible Xnest servers. This way the user can start new login screens in a nested window. Of course you must have the Xnest server from your X server packages installed for this to work.

Security Options



Allow root (privileged user) to log in through GDM. Set this to false if you want to disallow such logins.

On systems that support PAM, this parameter is not as useful as you can use PAM to do the same thing, and in fact do even more. However it is still followed, so you should probably leave it true for PAM systems.


Allow root (privileged user) to log in remotely through GDM. Set this to false if you want to disallow such logins. Remote logins are any logins that come in through the xdmcp.

On systems that support PAM, this parameter is not as useful as you can use PAM to do the same thing, and in fact do even more. However it is still followed, so you should probably leave it true for PAM systems.


Allow the timed login to work remotely. That is, remote connections through XDMCP will be allowed to log into the "TimedLogin" user by letting the login window time out, just like the local user on the first console.

Note that this can make a system quite insecure, and thus is off by default.


By default GDM checks the ownership of the home directories before writing to them, this prevents security issues in case of bad setup. However in some instances home directories will be owned by a different user and in this case it is necessary to turn this option on. You will also most likely have to turn the RelaxPermissions key to at least value 1 since in such a scenario home directories are likely to be group writable. Supported since


If true, then always append -nolisten tcp to the command line of local X servers, thus disallowing TCP connection. This is useful if you do not care for allowing remote connections, since the X protocol could really be potentially a security hazard to leave open, even though no known security problems exist.


Normally if this is true (which is by default), GDM will not place cookies into the users home directory if this directory is on NFS. Well, GDM will consider any filesystem with root-squashing an NFS filesystem. Sometimes however the remote file system can have root squashing and be safe (perhaps by using encryption). In this case set this to 'false'. Note that this option appeared in version and is ignored in previous versions.


By default GDM ignores files and directories writable to other users than the owner.

Changing the value of RelaxPermissions makes it possible to alter this behavior:

0 - Paranoia option. Only accepts user owned files and directories.

1 - Allow group writable files and directories.

2 - Allow world writable files and directories.


The number of seconds GDM should wait before reactivating the entry field after a failed login.


GDM will refuse to read/write files bigger than this number (specified in bytes).

In addition to the size check GDM is extremely picky about accessing files in user directories. It will not follow symlinks and can optionally refuse to read files and directories writable by other than the owner. See the RelaxPermissions option for more info.

XDCMP Support



To prevent attackers from filling up the pending queue, GDM will only allow one connection for each remote machine. If you want to provide display services to machines with more than one screen, you should increase the DisplaysPerHost value accordingly.

Note that the number of connections from the local machine is unlimited. Only remote connections are limited by this number.


Setting this to true enables XDMCP support allowing remote displays/X terminals to be managed by GDM.

gdm listens for requests on UDP port 177. See the Port option for more information.

If GDM is compiled to support it, access from remote displays can be controlled using the TCP Wrappers library. The service name is gdm

You should add
to your /etc/hosts.allow, depending on your TCP Wrappers configuration. See the hosts.allow(5) man page for details.

Please note that XDMCP is not a particularly secure protocol and that it is a good idea to block UDP port 177 on your firewall unless you really need it.


Enables XDMCP INDIRECT choosing (i.e. remote execution of gdmchooser) for X-terminals which don't supply their own display browser.


To avoid denial of service attacks, GDM has fixed size queue of pending connections. Only MaxPending displays can start at the same time.

Please note that this parameter does *not* limit the number of remote displays which can be managed. It only limits the number of displays initiating a connection simultaneously.


GDM will only provide MaxPendingIndirect displays with host choosers simultaneously. If more queries from different hosts come in, the oldest ones will be forgotten.


Determines the maximum number of remote display connections which will be managed simultaneously. I.e. the total number of remote displays that can use your host.


When GDM is ready to manage a display an ACCEPT packet is sent to it containing a unique session id which will be used in future XDMCP conversations.

GDM will then place the session id in the pending queue waiting for the display to respond with a MANAGE request.

If no response is received within MaxWait seconds, GDM will declare the display dead and erase it from the pending queue freeing up the slot for other displays.


The MaxWaitIndirect parameter determines the maximum number of seconds between the time where a user chooses a host and the subsequent indirect query where the user is connected to the host. When the timeout is exceeded, the information about the chosen host is forgotten and the indirect slot freed up for other displays. The information may be forgotten earlier if there are more hosts trying to send indirect queries then MaxPendingIndirect.


The UDP port number gdm should listen to for XDMCP requests. Don't change this unless you know what you are doing.


Interval in which to ping the X server in seconds. If the X server doesn't return before the next time we ping it, the connection is stopped and the session ended. This is a combination of the XDM PingInterval and PingTimeout, but in seconds.

Note that GDM in the past used to have a PingInterval configuration key which was also in minutes. For most purposes you'd want this setting to be lower then one minute however since in most cases where XDMCP would be used (such as terminal labs), a lag of more than 15 or so seconds would really mean that the terminal was turned off or rebooted and you would want to end the session.


When the server sends a WILLING packet back after a QUERY it sends a string that gives the current status of this server. The default message is the system ID, but it is possible to create a script that displays customized message. If this script doesn't exist or this key is empty the default message is sent. If this script succeeds and produces some output, the first line of it's output is sent (and only the first line). It runs at most once every 3 seconds to prevent possible denial of service by flooding the server with QUERY packets.

Common GUI Configuration Options



If to allow changing the GTK+ (widget) theme from the greeter. Currently this only affects the standard greeter as the graphical greeter does not yet have this ability. The theme will stay in effect on this display until changed and will affect all the other windows that are put up by GDM. Supported since


Path to a gtkrc to read when GDM puts up a window. You should really now use the GtkTheme key for just setting a theme.


A name of an installed theme to use by default. It will be used in the greeter, chooser and all other GUI windows put up by GDM. Supported since


Comma separated list of themes to allow. These must be the names of the themes installed in the standard locations for gtk themes. You can also specify 'all' to allow all installed themes. This is related to the AllowGtkThemeChange key. Supported since


Specifies the maximum icon width (in pixels) that the face browser will display. Icons larger than this will be scaled. This also affects icons in the XDMCP chooser.


Specifies the maximum icon height (in pixels) that the face browser will display. Icons larger than this will be scaled. This also affects icons in the XDMCP chooser.

Greeter Configuration



If the BackgroundType is 2, use this color in the background of the greeter. Also use it as the back of transparent images set on the background and if the BackgroundRemoteOnlyColor is set and this is a remote display. This only affects the Standard Greeter.


If the BackgroundType is 1, then display this file as the background in the greeter. This only affects the Standard Greeter.


If set this program will be run in the background while the login window is being displayed. Note that not all programs will run this way, since gdm does not usually have a home directory. You could set up home directory for the gdm user if you wish to run applications which require it. This only affects the Standard Greeter.


On remote displays only set the color background. This is to make network load lighter. The BackgroundProgram is also not run. This only affects the Standard Greeter.


Scale background image to fit the screen. This only affects the Standard Greeter.


The type of background to set. 0 is none, 1 is image and 2 is color. This only affects the Standard Greeter.


Set to true to enable the face browser. See the ``The Standard Greeter'' section for more information on the face browser. This option only works for the Standard Greeter. For the Graphical Greeter, the face browser is enabled by choosing a theme which includes a face browser


If true, add a chooser button to the Actions menu that will restart the current server with a chooser. XDMCP does not need to be enabled on the local machine for this to work.


Allow the configurator to be run from the greeter. Note that the user will need to type in the root password before the configurator is run however. See the Configurator option in the daemon section.


Default icon file for users without a personal picture in ~/gnome/photo. The image must be in an gdk-pixbuf supported format and the file must be readable for the gdm user.


Comma-separated list of usernames to exclude from the face browser. The excluded users will still be able to log in. See also MinimalUID.


Systemwide directory for face files. The sysadmin can place icons for users here without touching their homedirs. Faces are named after their users' logins.

I.e. <GlobalFaceDir>/johndoe would contain the face icon for the user ``johndoe''. No image format extension should be specified.

The face images must be stored in gdk-pixbuf supported formats and they must be readable for the GDM user.

A user's own icon file will always take precedence over the sysadmin provided one.


The graphical theme that the Graphical Greeter should use. it should refer to a directory in the theme directory set by GraphicalThemeDir.


The directory where themes for the Graphical Greeter are installed.


If present and /path/to/infofile specifies an existing and readable text file (e.g. /etc/infomsg.txt) the contents of the file will be displayed in a modal dialog box before the user is allowed to login. This works both with the standard and the themable greeters.


If present and InfoMsgFile (see above) is used, this specifies the font to use when displaying the contents of the InfoMsgFile text file. For example fontspec could be Sans 24 to get a sans serif font of size 24 points. This works both with the standard and the themable greeters.


File in format similar to the GNU locale format with entries for all supported languages on the system. The format is described above or in a comment inside that file.


If true the position of the login window of the Standard Greeter cannot be changed even if the title bar is turned on.


Image file to display in the logo box. The file must be in an gdk-pixbuf supported format and it must be readable by the GDM user. If no file is specified the logo feature is disabled. This only affects the Standard Greeter.


The minimal UID that gdm should consider a user. All users with a lower UID will be excluded from the face browser. See also Exclude.


The horizontal position of the login window of the Standard Greeter.


The vertical position of the login window of the Standard Greeter.


Controls whether gdmlogin should shake the display when an incorrect username/password is entered. This only affects the Standard Greeter.

RemoteWelcome=Welcome to %n

Controls which text to display next to the logo image in the greeter for remote XDMCP sessions. The same expansion is done here as in the Welcome string.


If this is true then the background program is run always, otherwise it is only run when the BackgroundType is 0 (None) This only affects the Standard Greeter.


If true the position of the login window of the Standard Greeter is determined by PositionX / PositionY.


Should the greeter show the Gnome Failsafe session in th sessions list.


Should the greeter show the 'Last' session in the session list. If this is off, then GDM is in the so called 'switchdesk' mode which for example Red Hat uses. That is, the users can't pick the last session and will just then get the default session (see DefaultSession) unless then pick something else for this session only. So if this is off, this really circumvents saving of the last session.


Should the greeter show the Xterm Failsafe session in the sessions list.


If true, the greeter will play a sound or beep when it is ready for a login. See also the SoundOnLoginFile key. Supported since


The file that will be played using the specified sound program (by default that is /usr/bin/play) instead of a beep when the greeter is ready for a login. See also the SoundOnLogin key and the SoundProgram key. Supported since


Turns the Actions menu (which used to be called System menu) on or off. If this is off then one of the actions will be available anywhere. These actions include Shutdown, Reboot, Configure, XDMCP chooser and such. All of those can however be turned off individually. Shutdown, Reboot and Suspend can be turned off by just setting the corresponding keys to empty. Note that the actions menu is only shown on local logins as it would not be safe or even desirable on remote logins, so you don't have to worry about remote users having any sort of console privilages.

Note that if this is off none of the actions will be available even if a theme for a graphical greeter mistakenly shows them. Also note that sometimes a graphical theme may not show all the available actions as buttons and you may have to press F10 to see the menu.


Display the title bar in the greeter. This only affects the Standard Greeter.


Force the use of 24 hour clock even if the locale would default to a 12 hour clock. In some locales that normally use 24 hour format (like czech, that is cs_CZ) this setting has no effect.


Use circles instead of asterisks in the password entry. This may not work with all fonts however.


Controls which text to display next to the logo image in the standard greeter. The following control chars are supported:

%% — the `%' character

%d — display's hostname

%h — Fully qualified hostname

%m — machine (processor type)

%n — Nodename (i.e. hostname without .domain)

%r — release (OS version)

%s — sysname (i.e. OS)

This string is only used for local logins. For remote XDMCP logins we use RemoteWelcome.

In the Graphical Greeter the location of this text depends on the theme. Unless the theme uses the stock welcome string somewhere this string will not be displayed at all.


If the Xinerama extension is active the login window will be centered on this physical screen (use 0 for the first screen, 1 for the second...).

XDCMP Chooser Options



If true, allow the user to add arbitrary hosts to the chooser. This way the user could connect to any host that responds to XDMCP queries from the chooser.


If true, the chooser will broadcast a query to the local network and collect responses. This way the chooser will always show all available managers on the network. If you need to add some hosts not local to this network, or if you don't want to use a broadcast, you can list them explicitly in the Hosts key.


If true and IPv6 is enabled, the chooser will send a multicast query to the local network and collect responses from the hosts who have joined multicast group. If you don't want to send a multicast, you can specify IPv6 address in the Hosts key. The host will respond if it is listening to XDMCP requests and IPv6 is enabled there.


This is the Link-local Multicast address and is hardcoded here.


File name for the default host icon. This image will be displayed if no icon is specified for a given host. The file must be in an gdk-pixbuf supported format and it must be readable for the GDM user.


Repository for host icon files. The sysadmin can place icons for remote hosts here and they will appear in gdmchooser.

The file name must match the fully qualified name (FQDN) for the host. The icons must be stored in gdk-pixbuf supported formats and they must be readable to the gdm user.


The hosts which should be listed in the chooser. The chooser will only list them if they respond. This is done in addition to broadcast (if Broadcast is set), so you need not list hosts on the local network. This is useful if your networking setup doesn't allow all hosts to be reachable by a broadcast packet.


Specifies how many seconds the chooser should wait for replies to its BROADCAST_QUERY. Really this is only the time in which we expect a reply. We will still add hosts to the list even if they reply after this time.

X Server definitions

To set up X servers, you need to provide gdm with information about the installed X servers. You can have as many different definitions as you wish, each identified with a unique name. The name Standard is required. If you do not specify this server, gdm will assume default values for a 'Standard' server and the path given by daemon/StandardXServer. Standard is used as the default, in situations when no other server has been defined.

Servers are defined by sections named server- followed by the identifier of this server. This should be a simple ASCII string with no spaces. If you use the GUI configurator, it will use random words for these. These will not be user visible, they are just needed to uniquely identify the server.


name=Standard server

The name that will be displayed to the user.


The command to execute, with full path to the binary of the X server, and any extra arguments needed.


Indicates if this server is available as a choice when a user wishes to run a flexible, on demand server.


Indicates that GDM should run the login window on this server and allow a user to log in. If set to false, then GDM will just run this server and wait for it to terminate. This can be useful to run an X terminal using GDM. When this is done you should normally also add -terminate to the command line of the server to make the server terminate after each session. otherwise the control of the slave will never come back to GDM and for example soft restarts won't work, since GDM assumes there is a login in progress for the entire time this server is active.


Indicates that GDM should instead of a login window run a chooser on this window and allow the user to choose which server to log into.

Local Static X Server Configuration

The static X servers are servers that are always running, when the server ever dies, it is restarted. You can have as many local static servers as you wish. Each key in the [servers] section corresponds to the display number of the server to run. For example normally there is only one key, which is the key 0, which corresponds to the display :0.


<display number>

Control section for local X servers. Each line indicates the local display number and the command that needs to be run to start the X server(s).

The command can either be a path to an X executable, or a name of one of the server definitions. This can be followed by some arguments that should be passed to the X server when executed.

The gdm daemon doesn't enforce the numbers to be in order or for them to be "packed". However when you use the GUI configurator, the servers will always start from 0 and go up by 1. That is, leaving no holes.

GDM will splice "-auth <ServAuthDir>/:n.Xauth :n", where n is the display number. Inside the command line before all other arguments before running the server.

On some systems it is necessary for gdm to know on which virtual consoles to run the X server. In this case, (if running XFree86) add "vt7" to the command line for example to run on virtual console 7. However on Linux and FreeBSD this is normally done automatically if VTAllocation key is set.

Normally you do not need to add a -nolisten tcp flag as this is added automatically for local servers when the DisallowTCP option is set.

Per User Configuration

There are some per user configuration settings that control how GDM behaves. Firstly there is the ~/.dmrc file. In theory this file should be shared between GDM and KDM, so users only have to configure things once. This is a standard .ini style configuration file. It has one section called [Desktop] and can have two keys, Session, which is the basename of the session .desktop file that the user wishes to normally use (but without the .desktop extension) and a Language key that is the language that the user wishes to use. If either of these keys is missing, the system default is used. The file would normally look as follows:


The user can also configure a face image for the face browser. This is done by copying an image into a file called ~/.face. This should be a standard image that GTK+ can read, such as PNG.

Face images can also be placed in the global face directory, which is normally <share>/faces/ (though this can be configured with the GlobalFaceDir configuration option) and the filename should be the name of the user, optionally with a .png appended.