Can you also deny CRAM-MD5?
Made no difference denying CRAM-MD5 either.
Can you try the following:
echo "mech_list: EXTERNAL PLAIN LOGIN GSSAPI GSS-SPNEGO" >>/etc/ldap/sasl2/slapd.conf
/etc/init.d/slapd restart
Does it help?
When searching to see the supported SASL mechanisms after running your command I see:
ldapsearch -h 172.16.0.9 -p 7389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
ldapsearch -h 172.16.0.9 -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: NTLM
WAIT! I think it did work. I can now login, I forgot to specify search path because it’s not automatically added. It’s still creating a local home folder and not mounting an NFS home.
This is the issue with NFS homes. The home shares don’t show up in the drop down menu. For some reason only one of my more recent shares shows up. Instead of the share where all the homes reside.
Here are the configurations for the two shares side by side. I’m not sure why the one on the right shows up in the “Home Share” drop down and the one on the left doesn’t.
Is NFS enabled for the Home-share?
cat /etc/exports
Yes
cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
"/users" -ro,no_root_squash,async,no_subtree_check * # LDAP:cn=users,cn=shares,dc=skaggscatholiccenter,dc=org
Readonly and async aren’t good options for a home share.
That’s just the root directory of the share. The homes inside obviously are not affected and have the proper permissions for the users currently mounting them over SMB.
AFAIK you want to use NFS for the home share, so it should be writable. But there is only a read-only NFS export of /users, so it isn’t writable. NFS export options have priority over file system permissions.
EDIT: Btw. I haven’t looked in the code of the UMC, but it makes totally sense for me filtering out read-only shares.
Well according to the UMC NFS write access is checked.
Then you should check the listener:
https://help.univention.com/t/troubleshooting-listener-notifier/6430
Relevant for the NFS-server is not the LDAP but the /etc/exports. You should also post the output of
univention-ldapsearch cn=users
I can make changes to the custom options area for NFS and they show up within seconds so it seems like that is already working.
Ok the exports file on the other server where the random share is showing up does have rw in it’s exports. So the question is why the main home server refuses to show rw and is instead stuck with ro.
Then you’re probably modifying the wrong LDAP object. They are only valid for one server. Please post the output of the command written above.
Figured it out. If I toggle off NFS support and save in the share and then toggle it back on and save. Then enable NFS write access and save it enables it in the exports file for the share. Problem is it’s still creating a local home folder instead of using the NFS share.
I don’t have a mac, but think you have to configure autofs.
I was able to create the automounts with the app “NFS Manager” which actually puts them into the Mac’s local Open Directory which is preferred over previous methods.
And after doing that I was able to correctly set the home folder in UCM.
1 Like