Shares not appearing in users Home share drop down

I have several shares made but only ONE of them will show in the dropdown for “Home Share” in the POSIX section in the Users > Account section. What makes a share appear or not appear in this list? I’ve compared the share available and the share I want to use I don’t see why one shows up and the other doesn’t.

As home directories are mounted via NFS, only those shares are offered. Pure Samba shares aren’t. The corresponding option is Export for NFS clients (NFSv3 and NFSv4) on the [Options] tab.

Here’s teh problem. There is no way to change “NFSHomeDirectory” attribute in UCS. It always has “/home/” prepended to it. Well if you see the “Home Directory” and “SMBHome” attributes, you can see it’s not “home” but “users”. I cannot edit this attribute either and change it to “/users/” like it should be.

This is a screenshot of the attribute in Apple’s Directory Utility’s Directory Browser.
58 PM

Please post the output of running the following command on your DC Master: univention-ldapsearch uid=nfstest1

I notice in the output it’s not showing the attribute “NFSHomeDirectory”

univention-ldapsearch uid=nfstest1
extended LDIF

base <dc=skaggscatholiccenter,dc=org> (default) with scope subtree
filter: uid=nfstest1
requesting: ALL

nfstest1, users,
dn: uid=nfstest1,cn=users,dc=skaggscatholiccenter,dc=org
uid: nfstest1
krb5PrincipalName: nfstest1@SKAGGSCATHOLICCENTER.ORG
objectClass: krb5KDCEntry
objectClass: person
objectClass: automount
objectClass: top
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: univentionPWHistory
objectClass: univentionMail
objectClass: univentionNetworkAccess
objectClass: shadowAccount
objectClass: univentionGoogleApps
objectClass: krb5Principal
objectClass: posixAccount
objectClass: univentionObject
uidNumber: 11907
sambaAcctFlags: [U          ]
sambaPasswordHistory: A2CADD5E38582EFE072EBAB31D93DDF235484CF21B93E3CA9C0130A4
krb5MaxLife: 86400
shadowLastChange: 17560
cn: NFS test1
sambaHomePath: \\\users\nfstest1
userPassword:: e2NyeXB0fSQ2JGRKVkdtd04wVC9Lbmp0UHUkd203NThpWE9QazFjdUIxRklvUTd
krb5Key:: MFqhKzApoAMCARKhIgQg86LYo70V7Z3uTReBoM9q3g+Z1HGyHqT6Tk5Xr6XC/UyiKzAp
krb5Key:: MFKhIzAhoAMCARChGgQYV5c9bUydQ+DsBNWJXX92L+qA5q2DdvIIoiswKaADAgEDoSIE
krb5MaxRenew: 604800
pwhistory: $6$8bFwKLXx1//lKAUK$.B3dQcchMDHanpqkTbrfZPKSPDBFCZn/vD5jOsJRUTX8rt0
univentionNetworkAccess: 1
loginShell: /bin/bash
univentionObjectType: users/user
krb5KDCFlags: 126
sambaPwdLastSet: 1517252738
sambaNTPassword: 5EDBB96115A271988A3545AE6918F017
telephoneNumber: 801-984-7
displayName: NFS test1
krb5KeyVersionNumber: 1
gecos: NFS test1
sn: test1
univentionGoogleAppsEnabled: 1
givenName: NFS
gidNumber: 5001
sambaPrimaryGroupSID: S-1-5-21-1764535785-503758966-3909477986-513
sambaSID: S-1-5-21-1764535785-503758966-3909477986-4314
homeDirectory: /users/nfstest1

search result
search: 3
result: 0 Success

numResponses: 2
numEntries: 1


That is correct — there is no such field in an OpenLDAP server (nor in the Samba4 LDAP server). I’m pretty sure that normally the value of the homeDirectory LDAP attribute should be used for NFSHomeDirectory. If it isn’t, as it seems to be the case in your case, please verify that your mac’s LDAP setup maps NFSHomeDirectory to the LDAPv3 attribute homeDirectory.

The QNAP support site has a pretty good article on how to set up macOS for connecting with OpenLDAP including screenshots. Please verify that your settings match the ones described there, especially the screenshot in step “g. Find “Users” > “NFSHomeDirectory” on the left side of “Record Types and Attributes”.”

Kind regards

Moritz, That is not applicable when a Mac is bound to UCS through Active Directory. I’m sorry if that was not clear in my original post. The original problem still stands that only one of my 20 or so shares system wide shows up in the “Home Share” drop down in Users > Account.

  1. I want to bind to Active Directory (much easier) but use NFS for home directories. THIS DOES NOT WORK ON UCS because it sends an incorrect NFSHomeDirectory attribute to the Mac.

  2. I could also bind to OpenLDAP and use NFS for home directories (with mapping as you suggested) BUT UCS DOESN’T LET ME BIND TO JUST OPENLDAP.

Do you see my frustration now?

I’ve tried to make this clear but we are losing something in translation. I really do like UCS, it’s a great product but it has some problems that are holding us back and I want to work with you guys in fixing them. Apple is killing off it’s server software and I really need a go to solution and I would prefer that to be UCS.


I already told you how to change that, albeit rather tersely. In the Univention Management Console edit one of the shares you want to use. Go to the “Options” tab and enable “Export for NFS clients”. Next go to the newly-appearing “NFS” tab and configure it how you want it.

However, that will most likely not help you:

Not entirely correct, but close: the Samba4 LDAP (that’s the Active Directory part you’re talking about) simply doesn’t contain that information. The home directory information is only present in the OpenLDAP part. You can see the difference by running univention-ldapsearch uid=nfstest (which you already showed me above; this queries the OpenLDAP portion) and univention-s4search cn=nfstest (this queries the Samba4 LDAP/Active Directory). There’s no easy way to make that information available in the Active Directory as you would have to extend the AD schema first, then tell the S4 Connector (the component synchronizing content between the OpenLDAP and the Samba4 LDAP) how to copy the data etc.

As the information isn’t present, your mac probably generates it automatically from default values (e.g. it simply concatenates the fixed /home/ with the user’s login name).

Then let’s try to figure out why binding to the OpenLDAP doesn’t work instead because that’s where all the information you need is actually available.

When trying to bind against UCS OpenLDAP you have to keep the following points in mind:

  1. The OpenLDAP server runs on the non-standard ports 7389 and 7636. 7389 is unencrypted by default but supports encryption via StartTLS. 7636 is always encrypted.
  2. By default the OpenLDAP server requires authentication before any search can be run. You can turn this off via the UCR variable ldap/acl/read/anonymous, but I advise against changing it.
  3. When binding against OpenLDAP, you have to use the full DN of an LDAP object as the user name. We usually have one user account dedicated for binding; I often call it ldapsearch. It’s full DN might be uid=ldapsearch,cn=users,dc=mbu-test,dc=intranet, and that’s exactly what I use as the login when configuring a service to connect to an OpenLDAP server.
  4. The general advice regarding TLS/SSL apply here, too. These are:
    1. The client (your mac) has to trust the certificate authority (CA) that signed the server’s certificate. UCS (just like Windows-based ADs) has its own CA it uses for signing all server certificates. Therefore you have to tell your mac to trust that CA. You can get the CA certificate from different places, e.g. the UCS Master in /etc/univention/ssl/ucsCA/CAcert.pem.
    2. The host name you configure your client to connect to is checked against the host name contained in the server certificate, and it doesn’t allow for any kind of mistakes. Therefore you really must tell your client to connect to the full-qualified domain name of your LDAP server, e.g. master.mbu-test.intranet.

As you seem to have connection against the Samba4 LDAP working, I assume that you do not have problems with TLS/SSL (meaning step 4 is likely fine already).

If that information isn’t enough for you to figure out how to bind against OpenLDAP, then please show some screenshots of the configuration you’ve tried and corresponding error messages and we’ll try to figure out what’s wrong.

Kind regards,

Ok, as you have suggested I have imported CAcert.pem into my test Mac into the system keychain and specified that it should “always trust” that certificate.

I created an “ldapsearch” user per the wiki article and according to the article it works as expected, I was able to search the administrator user with the ldapsearch user:

I entered the distinguised name uid=ldapsearch,cn=user,cn=skaggscatholiccenter,dc=org as well as the password for ldapsearch and I still can’t bind over ldap and I cannot even search the directory which I specified via it’s domain name so that SSL world work. I have tried port 7389 as well as enabling SSL and using 7636. Neither work.38 AM52 AM24 AM02 AM|5138 AM|636x50002 AM|517x50024 AM|570x50006 AM|517x50052 AM|517x50016 AM|632x5007x50016 AM06 AM

And yes UCS is doing a pure SMB share for our home folders (which is why it’s so slow).

From a different mac bound to the UCS ADDC as Active Directory instead of over LDAP

$ mount
/dev/disk2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
// on /home/nfstest1 (smbfs, nodev, nosuid, automounted, nobrowse, mounted by nfstest1)

You can see on the last line that it is mounted as “smbfs”.