Add A Domain Share On An External Ubuntu/Windows Server


I hope you are well. I recently discovered UCS and am still learning, so please bear with me. Is it possible to add a domain share on my UCS server that is on another server/s (Ubuntu and Windows)? I have been racking my brain for the past several days to work it out without success. Any suggestions?


Hey & welcome to UCS in general and the forum in particular.

Is it possible to add a domain share on my UCS server that is on another server/s (Ubuntu and Windows)?

It is possible, though not centrally managed. In Univention’s Management Console (the web-based administrative frontend) you only create shares for Univention servers, not for other servers. Instead you create the shares on the respective non-UCS servers themselves.

The easiest is creating shares on a Windows machine. You only have to join the Windows machine into the Active Directory domain provided by your Univention DC Master server. Then you can use the usual Windows-based method of adding a share: right-click on a folder in Windows Explorer, select “Sharing”, make it a share and optionally restrict the users & groups that have access to it. As the server is joined to the UCS AD domain, you can select AD users & groups there.

It’s more complicated for a Ubuntu machine as joining such a machine’s Samba service to the UCS domain is possible but involves several manual steps. There’s documentation avaialble for it. After a successful join you can configure Samba on your Ubuntu machine to provide a share.

There’s an alternative to joining that Ubuntu machine to the domain: let the Ubuntu machine provide an NFS export for a certain directory (e.g. /data/bigdrive), mount that NFS share on one of your Univention servers (e.g. in /net/ubuntu-server/bigdrive), and then use the Univention Management Console and configure a regular share that uses the mounted NFS share /net/ubuntu-server/bigdrive (make sure to make such a mount permanent, e.g. via /etc/fstab). The drawback of that method is that your Ubuntu server won’t be able to resolve user & group names to IDs and vice versa if it’s not joined into the domain. This means that accessing files & directories in /data/bigdrive directly on your Ubuntu server will lead to problems with access permissions.

1 Like

Thank you for your welcome and your reply Moritz.

Thanks. Ok just to confirm, as you mentioned that shares cannot be centrally managed. This means that any share created on an external server that is non-UCS server (even if joined to the UCS AD domain), will have to be connected to directly and not through the UCS AD server? This is what you meant by “centrally managed” and this also means you cannot add it in the Share section of the Univention Management Console?

Thanks for your time.


No. You only manage the creation of shares centrally. Connecting to shares, no matter if they’re created through central management in the UMC or manually on non-UCS servers, must be done another way.

When you create a share in the UMC, then what’s happening in the background is:

  1. The server that is supposed to offer the share checks whether the configured path exists, and if it doesn’t, it creates said path with the owner/group and permissions listed in the share configuration. If the path exists already, nothing will be done to it.
  2. A configuration snippet for Samba is created on said server containing the settings required to turn the configured path into an actual share with all the settings made in the UMC.
  3. Samba is reloaded so that the path is now shared on said server.

That’s all; that’s just the act of offering or providing the share.

Connecting to shares can be done in the usual ways on Windows including but not limited to:

  • Manually by navigating to the server offering the share in Windows Explorer, right-clicking on the share and selecting “map network drive” with the option of making it permanent
  • Writing a netlogon script that uses net share … commands during login
  • Creating group policies that map network shares during login

I suggest using group policies.

Kind regards,

1 Like

Thank you for the explanation Moritz. I think I am understand how UCS works a little better. So to summarise, centrally managed shares can only be stored on the UCS server and data shared on other servers are managed by that respective server, correct? If that’s the case:

In your example of creating a Windows share on a machine that is a part of the UCS domain, where you can restrict access to the share using the UCS AD users and groups, a user trying to connect to this share must authenticate against the machine serving the share and not the UCS AD, correct? Which means I must mirror the users and groups on that sharing server with that of the UCS server so users can successfully connect to the share?

Because this is what I am seeing in my tests. I am creating a share on a test Windows box which is joined to my UCS AD domain and have restricted access to a specific group (sharing and security). With another test Mac (also joined to the UCS AD domain), it cannot access the Windows share without needing a username and password (because there is no corresponding user to authenticate against on that Windows machine serving the share). But I was hoping that is what UCS does?

In the end, my main goal is to implement a central authentication server (AD or otherwise) that Windows, Mac and Linux workstations can log into and authenticate against and from there easily access all our multiple servers and multiple shares with the one central login. Is that possible with UCS?

Again thank you for your time and please excuse my ignorance.


Hi David,

No thats not true
if the windows machine where you’re creating a share and give rights to Domain Users/Groups only those Users have access and if they logged in to the domain (UCS Samba) they don’t have to extra login to the share


1 Like

Hi Christian,

Thanks for your reply.

If that’s the case, then I must be doing something wrong because every time I connect to that share, it will request a username and password.


Are you sure you’re logged in with AD user account not as local user to the Mac or Windows machine from where you are accessing the share ?


Yes, I am logging in as the Domain Administrator account but also tested it logging in as a standard domain user (a user which does not exist locally, only on the UCS AD).

I think I found the problem. I believe my test Windows machine that was hosting the share, even though it was bound to the AD, for some reason did not switch over to the “Domain Network” location profile, and was stuck in the Home location profile. It now decided to change to the Domain profile and now the machines accessing the share appear to authenticate without issue. I will continue my testing and let you know the result.


1 Like

No. If your Windows server is joined into the UCS AD domain, then all AD users and groups are available on the WIndows server as well. This applies both to authentication during login to the server as well as to mounting the share and to restricting access to the share. Meaning you don’t have to create users and groups manually on the Windows server. That’s the one huge advantage of having a domain in the first place: not having to manage users & groups in multiple places.

As for restricting access: you do that on Windows the same way you manage any kind of ACLs/access rights; right-click on the shared folder, select “Properties”, go to “Sharing” or something like that (different Windows versions may have the “sharing” in the popup menu already). Here you can select users & groups (both local and AD ones) that may connect to the share. If you want to restrict access to the folders and files within the shared folders, use ACLs; again right-click, “Properties”, “Security”, “Advanced” and add users & groups (again both local and AD ones) as needed.

1 Like

Thank you for all your help Moritz and Christian. It seems my test Windows machine with the incorrectly configured network profile was the fault. I have since successfully rolled out the UCS server since and users have been centrally authenticating through it to access shares.

Thank you so much.

Congratulation! And you’re quite welcome.