<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 4, 2018, at 21:56, Michael Chapman <<a href="mailto:mike@very.puzzling.org" class="">mike@very.puzzling.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Mon, 5 Feb 2018, Johannes Ernst wrote:<br class=""><blockquote type="cite" class="">It appears systemd-sysusers does not create home directories. On the other hand, it picks (largely unpredictable) UIDs from a range.<br class=""><br class="">So I have to run systemd-sysusers, and after that, find the UID of the user and chown the home directory? Or is there the equivalent of the “useradd -m” flag somewhere that I’m just not seeing?<br class=""></blockquote><br class="">systemd-sysusers is, as the name suggests, really for _system_ users, and often those kinds of users don't have ordinary home directories -- that is, ones the user can actually write to.</div></div></blockquote><div><br class=""></div>I agree with the “often” but not more :-)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">However, systemd-sysusers.service is ordered before systemd-tmpfiles-setup.service at boot, so if you need to create a system user's home directory and ensure its ownership is correct, you could use a corresponding tmpfiles.d fragment to do so.</div></div></blockquote></div><br class=""><div class="">Hmm … tmpfiles.d, according to its man page, is for “the creation,
cleaning and removal of volatile and temporary files and
directories which usually reside in directories such as
<code class="filename">/run</code> or <code class="filename">/tmp</code>.”. That doesn’t really seem to cover home directories that contain actual data.</div><div class=""><br class=""></div><div class="">Here’s my use case: Take a package for a daemon foo. The package contains a foo.service, and when foo runs, it is supposed to run in its own little place /var/lib/foo where it stores its data files. Because not everybody runs foo, it doesn’t make sense to pick a “fixed” UID like for more common daemons. Allocating a UID from a pool, like sysusers does, seems perfect. But how does the package ship /var/lib/foo? It can’t ship with owner foo because we don’t know what its UID is going to be. So the package, as part of its install script, needs to do something like:</div><div class=""><br class=""></div><div class="">systemd-sysusers</div><div class="">[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo</div><div class="">chown $(id -u foo):$(id -g foo) /var/lib/foo</div><div class=""><br class=""></div><div class="">I’d rather prefer a flag (if not the default) in the .conf file saying “create directory if it does not exist”. Perhaps worth adding?</div><div class=""><br class=""></div><div class="">But thanks for confirming that I didn’t miss anything, and I indeed need to jump through this hoop.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Johannes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>