Hey,
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 /home/<username> (e.g. \\fileserver\mbunkus → ~mbunkus → /home/mbunkus).
You can disable said built-in share by setting the UCR variable samba/share/home to no (default: yes).
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 Windows.
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.
The 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. \\master\sysvol\mbu-test.intranet\scripts\mylogon.bat The 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 /var/lib/samba/sysvol/<domain>/scripts.
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: \\fileserver\mbunkus\windows-profiles\default
You still have to ensure that the share actually exists (in my case the share mbunkus on 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 [1] 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 mbunkus on fileserver is /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
/home on fileserver,
- 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 /home + mbunkus = /home/mbunkus).
Alright. Let’s get back to your requirements.
On Windows the folders Desktop, 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 Desktop or 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.
[1] 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).
Kind regards
mosu
