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?
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.
|show 1 more comment|
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
If you have an existing
In the [Greeter] section of
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
N.B.#2 : The non-display of accounts with UID's below 1000 is a configurable parameter. By default, the
I haven't tested whether the reverse setting, namely, that setting an
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...
I don't know whether appending