On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe(a)mailbox.org wrote: Normally when I debug automounter issues, I used to run automount -m on the foreground in one terminal and try to correlate those with the sssd logs tailing in another terminal. Can you paste those?

Thanks, for your advice! I stopped the automounter daemon and run the automounter in the foreground: root@fs1:~# automount -f -v Starting automounter version 5.1.2, master map /etc/auto.master using kernel protocol version 5.02 no mounts in table After that, I restart the sssd daemon and dump the automounter maps in another terminal: root@fs1:~# automount -m autofs dump map information =========================== global options: none configured no master map entries found However the automounter still gives no further output. After that, I moved the empty /etc/auto.master away and restart the automounter in the foreground: root@fs1:~# automount -f -v Starting automounter version 5.1.2, master map /etc/auto.master using kernel protocol version 5.02 lookup(file): file map /etc/auto.master missing or not readable no mounts in table No additional output from the automounter after restarting sssd. In the logs of the sssd at startup I found the following: ... (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): Option ldap_autofs_search_base has value ou=automount,dc=informatik,dc=privat ... (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): Option ldap_autofs_map_master_name has value auto.master ... Why is the automounter not looking for the maps from the sssd daemon? I think, that the automounter doesn't communicate with the sssd daemon for automounter maps, although the nsswitch.conf looks like this: ... automount: files sss ... Do I miss something or how can I narrow down the problem? Thanks! Peter > > > > OS: Ubuntu 18.04.3 LTS > > sssd 1.16.1-1ubuntu1.4 > > sssd-ad 1.16.1-1ubuntu1.4 > > sssd-ad-common 1.16.1-1ubuntu1.4 > > sssd-common 1.16.1-1ubuntu1.4 > > sssd-dbus 1.16.1-1ubuntu1.4 > > sssd-ipa 1.16.1-1ubuntu1.4 > > sssd-krb5 1.16.1-1ubuntu1.4 > > sssd-krb5-common 1.16.1-1ubuntu1.4 > > sssd-ldap 1.16.1-1ubuntu1.4 > > sssd-proxy 1.16.1-1ubuntu1.4 > > sssd-tools 1.16.1-1ubuntu1.4 > > > > > > > > Here is the configuration. Additionally, I attached logfiles with log_level 9 > > > > > > > > ****sssd.conf**** > > > > [sssd] > > domains = info.privat > > config_file_version = 2 > > services = nss, pam, autofs > > > > [pam] > > > > [nss] > > > > [autofs] > > > > [domain/info.privat] > > debug_level = 5 > > ad_server = tfaddc2.info.privat > > access_provider = ad > > auth_provider = ad > > krb5_realm = INFO.PRIVAT > > cache_credentials = True > > id_provider = ad > > > > autofs_provider = ad > > ldap_autofs_entry_key = cn > > ldap_autofs_entry_object_class = nisObject > > ldap_autofs_entry_value = nisMapEntry > > ldap_autofs_map_name = nisMapName > > ldap_autofs_map_object_class = nisMap > > ldap_autofs_search_base = ou=automount,dc=info,dc=privat > > > > > > nsswitch.conf > > > > automount: files sss > > > > > > ****AD**** > > > > dn: OU=automount,DC=info,DC=privat > > objectClass: top > > objectClass: organizationalUnit > > ou: automount > > name: automount > > > > dn: CN=auto.master,OU=automount,DC=info,DC=privat > > objectClass: top > > objectClass: nisMap > > cn: auto.master > > name: auto.master > > objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat > > nisMapName: auto.master > > > > dn: CN=auto.home,OU=automount,DC=info,DC=privat > > objectClass: top > > objectClass: nisMap > > cn: auto.home > > name: auto.home > > objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat > > nisMapName: auto.home > > > > dn: CN=/home/,CN=auto.master,OU=automount,DC=info,DC=privat > > objectClass: top > > objectClass: nisObject > > objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat > > nisMapName: auto.master > > cn: /home/ > > name: /home/ > > nisMapEntry: auto.home > > > > dn: CN=user1,CN=auto.home,OU=automount,DC=info,DC=privat > > objectClass: top > > objectClass: nisObject > > objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat > > nisMapName: auto.home > > nisMapEntry: -fstype=nfsv4,nosuid,rw,dir_index,user_xattr,proto=tcp,port=2049 server:/export/lra/user/user1 > > cn: user1 > > name: user1 > > > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste... > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...

These processes are running concerning ssd: /usr/sbin/sssd -i --logger=files /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain informatik.privat --uid 0 --gid 0 --logger=files /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files /usr/lib/x86_64-linux-gnu/sssd/sssd_autofs --uid 0 --gid 0 --logger=files Seems to be installed: ./usr/lib/x86_64-linux-gnu/sssd/modules/libsss_autofs.so Also the socket seems to be created: ls -l /var/lib/sss/pipes/ total 4 srw-rw-rw- 1 root root 0 Sep 27 09:15 autofs srw-rw-rw- 1 root root 0 Sep 27 09:15 nss srw-rw-rw- 1 root root 0 Sep 27 09:15 pam drwx------ 2 sssd sssd 4096 Sep 27 09:15 private However, when I strace automount, there is no access to the sssd socket: ... munmap(0x7fdaff1ac000, 39635) = 0 futex(0x7fdafeb6b6a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/autofs/lookup_file.so", O_RDONLY|O_CLOEXEC) = 6 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\220\0\0\0\0\0\0"..., 832) = 832 fstat(6, {st_mode=S_IFREG|0644, st_size=194496, ...}) = 0 mmap(NULL, 2295984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x7fdafb4a7000 mprotect(0x7fdafb4d4000, 2097152, PROT_NONE) = 0 mmap(0x7fdafb6d4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x2d000) = 0x7fdafb6d4000 mmap(0x7fdafb6d6000, 6320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fdafb6d6000 close(6) = 0 mprotect(0x7fdafb6d4000, 4096, PROT_READ) = 0 access("/etc/auto.master", R_OK) = -1 ENOENT (No such file or directory) write(2, "lookup(file): file map /etc/auto"..., 63) = 63 .... Hm, what is missing here?

Finally I found the issue. You are right it is on the automounter config side. I had to modify either the /etc/autofs.conf : .. [ autofs ] # # master_map_name - default map name for the master map. # # default: #master_map_name = /etc/auto.master # new: master_map_name = auto.master .. or leave /etc/autofs.conf default and modify /etc/auto.master /etc/auto.master: ... # old # /home /etc/auto.home # new /home auto.home Anyway, removing the absolute path to the automappper file makes the difference Thanks for your reply! Peter > Jakub Hrozek <jhrozek(a)redhat.com&gt; hat am 30. September 2019 um 09:23 geschrieben: > > > On Fri, Sep 27, 2019 at 01:05:17PM +0200, wipe(a)mailbox.org wrote: > > > > > Jakub Hrozek <jhrozek(a)redhat.com&gt; hat am 27. September 2019 um 09:55 geschrieben: > > > > > > > > > On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe(a)mailbox.org wrote: > > > > > > > > > Jakub Hrozek <jhrozek(a)redhat.com&gt; hat am 26. September 2019 um 14:52 geschrieben: > > > > > > > > > > > > > > > On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe(a)mailbox.org wrote: > > > > > > Hello list, > > > > > > I'm trying to setup sssd to access automounter rules stored on an AD (samba 4.7.6). > > > > > > I followed the instructions on this site, however it doesn't work for me. > > > > > > https://ovalousek.wordpress.com/2015/08/03/autofs/ > > > > > > In the sssd_logfile I see, that the "auto.master" map is found by sssd within the ldap search path. > > > > > > However, the reference to the auto.home and the corresponding user mounts does not seem to be found. > > > > > > > > > > > > Using sssd to authenticate against Active Directory works well. > > > > > > > > > > > > Any ideas what's going wrong here? Thanks for looking in this issue! > > > > > > > > > > Normally when I debug automounter issues, I used to run automount -m on > > > > > the foreground in one terminal and try to correlate those with the sssd > > > > > logs tailing in another terminal. > > > > > > > > > > Can you paste those? > > > > > > > > Thanks, for your advice! > > > > I stopped the automounter daemon and run the automounter in the foreground: > > > > > > > > root@fs1:~# automount -f -v > > > > Starting automounter version 5.1.2, master map /etc/auto.master > > > > using kernel protocol version 5.02 > > > > no mounts in table > > > > > > > > After that, I restart the sssd daemon and dump the automounter maps in another terminal: > > > > > > > > root@fs1:~# automount -m > > > > > > > > autofs dump map information > > > > =========================== > > > > > > > > global options: none configured > > > > no master map entries found > > > > > > > > > > > > However the automounter still gives no further output. > > > > After that, I moved the empty /etc/auto.master away and restart the automounter in the foreground: > > > > > > > > root@fs1:~# automount -f -v > > > > Starting automounter version 5.1.2, master map /etc/auto.master > > > > using kernel protocol version 5.02 > > > > lookup(file): file map /etc/auto.master missing or not readable no mounts in table > > > > > > > > No additional output from the automounter after restarting sssd. > > > > In the logs of the sssd at startup I found the following: > > > > > > > > ... > > > > (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): Option ldap_autofs_search_base has value ou=automount,dc=informatik,dc=privat > > > > ... > > > > (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): Option ldap_autofs_map_master_name has value auto.master > > > > ... > > > > > > > > Why is the automounter not looking for the maps from the sssd daemon? I think, that the automounter doesn't communicate with the sssd daemon for automounter maps, although the nsswitch.conf looks like this: > > > > > > > > ... > > > > automount: files sss > > > > ... > > > > > > > > > > > > Do I miss something or how can I narrow down the problem? > > > > > > Is the autofs responder of sssd running? > > > > These processes are running concerning ssd: > > /usr/sbin/sssd -i --logger=files > > /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain informatik.privat --uid 0 --gid 0 --logger=files > > /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files > > /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files > > /usr/lib/x86_64-linux-gnu/sssd/sssd_autofs --uid 0 --gid 0 --logger=files > > > > > > > Is libsss_autofs installed? > > > > Seems to be installed: > > ./usr/lib/x86_64-linux-gnu/sssd/modules/libsss_autofs.so > > > > > > > > > > If you strace automount, can you see it contacting the sssd socket? > > > > Also the socket seems to be created: > > ls -l /var/lib/sss/pipes/ > > total 4 > > srw-rw-rw- 1 root root 0 Sep 27 09:15 autofs > > srw-rw-rw- 1 root root 0 Sep 27 09:15 nss > > srw-rw-rw- 1 root root 0 Sep 27 09:15 pam > > drwx------ 2 sssd sssd 4096 Sep 27 09:15 private > > > > > > However, when I strace automount, there is no access to the sssd socket: > > ... > > munmap(0x7fdaff1ac000, 39635) = 0 > > futex(0x7fdafeb6b6a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > > openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/autofs/lookup_file.so", O_RDONLY|O_CLOEXEC) = 6 > > read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\220\0\0\0\0\0\0"..., 832) = 832 > > fstat(6, {st_mode=S_IFREG|0644, st_size=194496, ...}) = 0 > > mmap(NULL, 2295984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x7fdafb4a7000 > > mprotect(0x7fdafb4d4000, 2097152, PROT_NONE) = 0 > > mmap(0x7fdafb6d4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x2d000) = 0x7fdafb6d4000 > > mmap(0x7fdafb6d6000, 6320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fdafb6d6000 > > close(6) = 0 > > mprotect(0x7fdafb6d4000, 4096, PROT_READ) = 0 > > access("/etc/auto.master", R_OK) = -1 ENOENT (No such file or directory) > > write(2, "lookup(file): file map /etc/auto"..., 63) = 63 > > .... > > > > Hm, what is missing here? > > This seems to point to the automounter side? > > I briefly checked the fedora package, but did not see any sssd > specific option. But I remember from way when this feature was written > that there was also some plumbing for the sss client created on the > autofs side. > > Maybe ask the ubuntu automounter maintainer if the autofs support is > enabled. > > Or maybe there are some Ubuntu users on this list using automounter? > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...