I’ll start with a general explanation about all the settings available for the user — because I often need it, and so far I only have one in German. Bear with me; I’ll get to your situation later.
By default there’s a Samba share for the home directories of each user. This share is configured via the
[homes] section in
smb.conf. It’s a built-in share in UCS that you cannot see nor change in the Univention Management Console. It’s this share that enables users to connect to
\\fileserver\<username>. The corresponding path in Linux is
~<username>, meaning the Linux home directory for
<username>, which is usually
You can disable said built-in share by setting the UCR variable
So far this is completely independent of the user’s Windows settings in the UMC. Let’s talk about those next: the settings on the
Account tab, section
The two settings
Windows home drive and
Windows home path work together. If the latter is set to a UNC path, that path is connected as the drive letter given by the former setting when the user logs in. For example, I might set
H: as the drive and let the OS mount my home share
\\fileserver\mbunkus there. The share given by the UNC path must exist, of course; my example should work as it refers to my home drive as explained above.
Windows login script can contain a UNC path to a script (e.g. a
.bat file or a PowerShell script) that will be executed during login, e.g.
sysvol share is a good choice for such scripts as it always exists in a Samba4 Active Directory domain. The corresponding Linux path for that share is
Let’s talk about the
Windows profile directory next. Here you can enter a UNC path to a directory where roaming profiles for users will be stored. The actual path used by the client depends on the version of the operating system; for example, Windows 10 appends
.V2 to whatever’s been set as the
Windows profile directory. Example:
You still have to ensure that the share actually exists (in my case the share
fileserver). Again, my example should work fine for me as that’s my own home directory for which there’s a share by default.
If you do want to use romaing profiles but you do not want to store them in the user’s home directory in Linux but in another one (e.g. in
/srv/windows-profiles/<username> instead of
/home/<username>/windows-profiles), you have to create a Windows share for
/srv/windows-profiles in the UMC first, e.g. with the name
windows-profiles. Next you set your user’s
Windows profile path setting to
\\fileserver\windows-profiles\<username>\default. Of course you must make sure that
/srv/windows-profiles/<username> actually exists as it won’t be created automatically (this is different for the home directories; read my footnote  below).
All of the above has nothing to do with the settings named
Home share and
Home share path in the section
POSIX (Linux/Unix)! Nothing at all!
The settings in that section are used in order to mount a user’s home directory from one Linux server to another Linux server via NFS. For example, if the home directory of user
/home/mbunkus and I want to have the same path available when I ssh into the
databaseserver, I have to do the following:
- Create an NFS share in the UMC for the path
- Configure the user
mbunkus so that the
Home share is set to the name of the share I created in step 1, likely something like
home (/home one fileserver) and
- Set the
Home share path to
mbunkus (this path is relative to the share’s path selected in step 2, effectively
Alright. Let’s get back to your requirements.
On Windows the folders
Downloads are both part of the user’s profile. If you want to use roaming profiles, those folders will be synchronized with the server. Assuming you want to keep roaming profiles in your user’s home directory on your server
domain-controller, you might find the server-side copy of the
Desktop folder for a Windows 10 client in
/home/<username>/windows-profiles/default.V2/Desktop. You can easily symlink that folder into the user’s home directory, e.g.
ln -s ~username/windows-profiles/default.V2/Desktop ~username/
You can then combine that with mounting the
/home directory from the
domain-controller server via NFS to the Linux server/client.
One of the drawbacks of that solution is that roaming profiles are only synced with the server during login & logout. If you create a new entry on your Windows client’s desktop, that entry will only show up on the server when the you log out of your current session.
Another possibility is to use Windows’ folder redirection (google for that term and you’ll find plenty of hits). It’s a mechanism that tells Windows that it should look for certain folders such as
Downloads not in the user’s profile directory but somewhere else — e.g. on a mapped network drive. You can use group policies for enabling folder redirection. The advantage is that all accesses to the redirected folders will occur in real time; meaning as soon as you create a new entry in
Desktop, it’ll show up on the server. The obvious drawback is that the server has to be reachable in that moment; you cannot work with such paths if your PC is not currently connected to your server.
 A lot of services on a UCS server are configured via PAM to create the user’s home directory if it doesn’t exist. The first time a user logs in to a server, e.g. via ssh or by accessing a Windows share via Samba, his/her home directory will be created automatically and filled with content from the template directory
/etc/univention/skel. That template contains the
windows-profiles directory — that’s why e.g.
/home/mbunkus/windows-profiles will be created the first time I log in).