Description of problem: the '-d' option is for specifying a non default user directory. As it says in the man page, https://linux.die.net/man/8/useradd : -d, --home HOME_DIR The new user will be created using HOME_DIR as the value for the user's login directory. The default is to append the LOGIN name to BASE_DIR and use that as the login directory name. The directory HOME_DIR does not have to exist but will not be created if it is missing. Note the last sentence: "The directory HOME_DIR does not have to exist but will not be created if it is missing." Version-Release number of selected component (if applicable): How reproducible: very Steps to Reproduce: # ls /home/temp2 # useradd tomjones -d /home/temp2/tj # ls /home/temp2 tj # Actual results: the -d option directory is created Expected results: the -d option directory will not be created Additional info: To setfacls for the directory the home dir is to be put in requires to first create the user (I think this is the case, seems funny to make up a non-existent user.) So the home dir created by useradd has the wrong permissions as it is created before facls are set on the directory it is in. Perhaps there is a scenario where a user directory is mounted when it isn't in the file system? This would mess that up. The biggest problem here is that by not acting as specified scripts are throwing errors. A simple fix seems to be to modify the calling script to delete the home dir after the useradd call, then continue as it did before.
Did you mean to file this bug against libuser? useradd comes from shadow-utils..
thanks I was initially on the fence about that .. should know better, I've forked shadow locally to look at it ..
By default there is CREATE_HOME yes in /etc/login.defs which overrides what is specified in the manpage for -d. Please see the -m and -M options to override it.
Hold on a sec. Options that are effected by the login.defs are explicitly marked as such on the man page. Note, -g and -U options. This leaves the reading that The CREATE_HOME variable in login defs affects only the default behavior, not when explicitly specified as it states for the -d option. Indeed the man page says: "CREATE HOME ... if a home directory should be created by default ..." as quoted above, -d option gives explicit no create behavior. If the man page is incorrect, like how could anyone know that? If that is the case I'll flip it over to those guys. BTW, I did bring this up in an issue on the shadow github, but no one commented on it. So like other people, I'm left with the man page for documentation.
The manpage is what should be clarified.
Tomas, am I to understand that there is no way to invoke useradd on Fedora without having a user directory created and populated?
(In reply to Thomas Walker Lynch from comment #6) > Tomas, am I to understand that there is no way to invoke useradd on Fedora > without having a user directory created and populated? excuse me, -M works for this and is working in combination with -d. So the unqualified clause in the -d option, that the directory will not be created, is what needs clarification
Yes.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
* master d60b59b156a576293986a4ccf182db09e3386236 - useradd: clarify the useradd -d parameter behavior in man page
FEDORA-2020-4ece7634c3 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ece7634c3
FEDORA-2020-4ece7634c3 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4ece7634c3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ece7634c3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-fec3968448 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fec3968448
FEDORA-2020-4ece7634c3 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-fec3968448 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fec3968448` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fec3968448 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-fec3968448 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
This is not 100% correct -d, --home-dir HOME_DIR The new user will be created using HOME_DIR as the value for the user's login directory. The default is to append the LOGIN name to BASE_DIR and use that as the login directory name. If the directory HOME_DIR does not exist, then it will be created unless the -M option is specified. The home directory will be created if the -m option is set or CREATE_HOME is set to true in /etc/login.defs. Using the -M option prevents creating the directory regardless of the value of CREATE_HOME.