when i write useradd -D i get in the shell argument /bin/bash

i know how to change it (useradd -D -s the_shell_name)
but how can i erase it, make it empty?

If you have root access you can edit /etc/passwd and remove the shell name from after the last colon. Also, systems like Slackware have a usermod command that you can use - try `man usermod` for details.

i know that but i want to do it with out configuring any file.
but i want to change the default and not to change a file every time im adding a user.

The default settings are usually taken from files in /etc/skel (short for skeleton) or something.
All that the -D option does is modify those skeleton (template if you will) files. The next time you'll
add a user, the changes by -D will be read from the modified skel files.

So, my suggestion is:
-check out where your skeleton files are located (try "man useradd")
-modify those once (as root).
After that, all your new user should have the settings you want.

Just maybe, useradd -D -s '' or something will work too.

I must say that it's not very clear to me why you want empty shells. This will probably only result in errors. If you want to deny shell logins to certain users, try using /etc/nologin or /bin/false or something as shell (depends somewhat on your system). See "man nologin".

actually i dont want to change the shell to empty, it was just an example, i could asked about any of the arguments. i just wanted to learn how to do that cos i know how to add or modify one of the argument in the useradd -D but didnt knew how to delete. now i know, 10x.

Don't set the user's shell to be empty if you don't want them having a login shell. Set it to /bin/false {/bin/true also works and I think it is slightly more amusing}.

If you want a user to be able to connect by FTP but not have shell login access, then add a line reading /bin/false to the file /etc/shells.

my FTP server reason my first tough why i dont want users able to be connect with shells by default.
i want to make a scrip to my FTP server for opening users on him but i dont want them to having a shell.
whats the different if its false or none?

If you leave the shell field blank for a user, behaviour is undefined whenm that user tries to log in. You'll have to look at the source code of the "login" command {available from your distribution's web site} to figure out what will happen. It should specify a program which does something; ideally interpret commands.

The purpose of /etc/shells is to give ProFTPD a hint as to which users to let in, based on their default shell in /etc/passwd. I use /bin/bash for a "normal" user, /bin/false {which is in /etc/shells} for an "email and FTP only" user and /bin/true {which is not in /etc/shells} for an "email only" user.

/bin/false is just a little program that swallows any input from STDIN, and exits without generating any output on STDOUT or error messages on STDERR -- just a "not OK" error code. /bin/true is similar, but exits with an "OK" code. {The login program behaves a little differently depending whether the last "shell" it launched exited cleanly or not; I think the true one is a bit funnier but that's just my warped sense of humour.} The original usage of these programs was in shell scripts, where "false" or "true" could be used for testing complex conditional expressions. Bash actually has "true" and "false" as built-in commands; but older command shells didn't, so they have to stay around just in case.

Assuming you have the bsdgames package installed, try something like
Now go to another virtual console {ctrl + alt + f1-f6} and login as "somebody" with the password you just gave ..... and you should find that you go straight into a game of adventure.

If you have it, using the "nologin" program is actually better than the "false" or "true" programs.
"nologin" is especially provided to disallow logins, so it's simply better suited for the job.

As for having FTP users without a real login, you should consider using "virtual users". Most modern FTP daemons, like vsftpd - and probably also proftpd - support this feature.
Simply said, you create a database of ftp users that don't have real logins (no real users, so they're called
virtual users) and you allow users access to FTP if they have a login in that database.
Internally, all virtual users, if their login succeeds, are then mapped to just one real user (the so-called FTP 'guest user'). This user should be put in a chroot jail after login and should have many other security restrictions as well (ie limited uploading/downloading of files).

How so?

As I understand it, if /etc/nologin exists then /bin/login will display the contents of this file and exit, unless you try to login as root. This means only root can login. While this may be desirable for systems under maintenance {e.g. while the disc on which /home resides is being repaired} it isn't much good if you want to be able to allow some users to login to a shell, but not others.
Accomplishing what, exactly?

The chances are that all users will want an e-mail account, which requires individual user accounts anyway; and most will want web hosting, thereby {unfortunately IMHO} implying FTP. Apache makes it easy to set up virtual hosts using directories, so the logical thing is just to use users' individual home directories as the ServerRoot for their website.

[QUOTE]
A quote from "man nologin":
It is inteded as a replacement shell field for accounts that have been disabled.
I just mentioned the notion of "virtual users" for completeness. If you use it or not, depends on your system. In this case, it would be easier indeed to set up real users.
I just didn't consider the possibilities of web hosting/e-mail for the users. Maybe I misread the post or was too fast to jump to conclusions.
My bad...