I have recently added several new users, that I need for qmail. Now they appear in the box in the login screen and clutter it, and I have to scroll to find my user. How can I hide those users from the login box?
I have recently added several new users, that I need for qmail. Now they appear in the box in the login screen and clutter it, and I have to scroll to find my user. How can I hide those users from the login box?
For newer GDM 3.X, old answers don't work, except for this one
The
greeter
setting incustom.conf
is obsolete, i.e. it won't work anymore. One easy workaround if you want to avoid changing the uid of the user:Open the terminal, and enter (replace
user
with the username you want to hide from the login screen):Add the following to the file:
Switch user or log out to test if
user
is not listed anymore.Edit the file /etc/gdm/gdm.schema find the section that currently looks like this:
And to exclude a user called qmail for example add qmail to the default list so the section looks like this.
That will stop user qmail appearing in the gdm greeter. There used to be a nice GUI tool to do this but is has not been in Ubuntu for the last few releases.
The other alternative is to set the UID of the user to under 1000. Those are considered to be system accounts which are excluded in the GDM greeter too.
Hacky but you can modify the user's id so they don't show in the list:
This works because users with id under 1000 are considered to be "system" users (i.e. not humans).
The only other way I know is to hide the list completely:
Elaborating on Gilles's comment to the accepted answer, here's what I believe is the current "best practices" (Gnome-safe) way to do this. This change will also be reflected in the Gnome "Indicator Applet Session".
This method is that one suggested in the docs at the GDM website, and though both the site and Gilles show the addition of "nobody" to the exclude, I wanted to make sure that it was clear this is actually necessary (despite what the manpages or online docs explicitly offer). I've tested this on a couple of 10.10 systems to verify repeatability.
All we need to do is to make on one-line edit to
/etc/gdm/custom.conf
. Most other methods (making changes to default.conf, gdm.conf, etc.) are deprecated.If you have an existing
/etc/gdm/custom.conf
, edit that file. Otherwise, copy over the example file :In the [Greeter] section of
/etc/gdm/custom.conf
, add:Where "user1" and "user2" are the usernames or passwd file entries (e.g., qmail, squid, etc.) that you do not wish to show on the GDM "face browser".
Note : Under my version of Gnome/GDM (2.30), if you do not have "nobody" listed in the Exclude entry, then you will have a bogus login user
nobody
show up instead of user1 or user2.N.B.#2 : The non-display of accounts with UID's below 1000 is a configurable parameter. By default, the
MinimalUID
value is set to 1000. If and only if the default settingIncludeAll=true
is left in place and theInclude
directive is not changed to a non-empty value, does the GDM greeter scan the passwd file for entries with UID's greater than MinimalUID. Users with UID's above MinimalUID that are not in the Exclude list are then displayed.I haven't tested whether the reverse setting, namely, that setting an
Include=user1,user2
entry in custom.conf will work as presented. It should override anyIncludeAll
setting, and display only the users explicitly listed.I wrote a script (gdm-greeter) this weekend. It works well on CentOS 6.2, I wonder if it will be useful for Ubuntu?
I'd have to agree that the most accepted answer here is close, but not dead on.
I just licked this problem myself, and the answer for me was to alter the following gdm.schema entry:
The effect of this is that all user-listing is disabled, which if I'm interpreting the original question correctly, is actually what the OP (gruszczy) was intending to do. This eliminates the need to craft a long line of excludes, as all userIDs regardless of UID number are excluded regardless once this setting is altered. I've personally applied this setting to 3 separate CentOS 6.2 servers at work that are occasionally accessed via XDMCP (using xrdp > vnc-server > xinetd > gdm > gnome) over RDP, which allows some of our less experienced Linux admins work on these systems with minimal training.
All of that said, while I do agree that an inexperienced sysadmin should learn from the beginning to work from a personal account (maybe with sudo access) rather than as root, if you have the experience to work with that account properly, there's no harm in doing so. Just make sure you know what you're doing before hand. In the case of my other sysadmins, I've added CentrifyDC for Active Directory support to all of these systems and configured the systems so that the AD-UserIDs can be used for desktop sessions while maintaining the user's AD Security Group rights. But personally, since I engineered all of these servers and have used Linux for over 15 years now, I think nothing of using root to speed things along. In fact, I tend to enable root on systems where it's been disabled just so that I can use that account and cut to the chase with getting things done. The main thing there, really, is just to make a habit of creating a backup copy of any file before you alter it. That will safe guard against most mishaps and allow you to recover the system should you perform an edit that would otherwise cause the system to become inaccessible (just boot to a live CD and fix up what needs to be fixed up).
IMHO, I believe that the mantra of 'never login as root' is really just there to protect the n00bie sysadmins from themselves. But if you reach a level of competence with Linux to the point where you can engineer a system from any Linux OS in a very short amount of time and it work every time, then there's no reason to live by the 'never login as root' mantra because by that point you're ready to handle the responsibility that comes along with using that account. This is especially true in environments that use CentrifyDC for AD support, because 'root' becomes the local sysadmin account and is (usually) enabled automatically. So, I find it best to cut to the chase and make the setting of the root account's password as one of the very first tasks I do on any deployment nowadays. Sure, I could do the whole 'login as my own ID, then sudo up', but I personally don't feel the need to do things that way. Your own mileage may vary...
Change the user login shell to an empty string in /etc/passwd
For Example, change:
I restarted my display manager and observed this taking effect.
It took me weeks to identify this as the reason why users were hidden in the display manager login greeter. It is apparent that /var/lib/AccountService/users is being ignored by MDM, and assumedly GDM as well. I didn't go as far as to add an
Exclude=user1,user2
or anInclude=user3
under[greeter]
in /etc/mdm/mdm.conf, or create an /etc/mdm/custom.conf, as a another box was hiding users added viauseradd
just fine, while users added withadduser
were shown. Setting the login shell to /bin/false denies all login to that user, which I still wish to su as. But that also hides the user in the login screen if you want that user to be plain inaccessible.This worked for me on Zorin 16 - gdm3
Uncomment the line which says disable-user-list=true in /etc/gdm3/greeter.dconf-defaults
Then