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!
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
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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?
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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 that 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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?
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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?
Is libsss_autofs installed?
If you strace automount, can you see it contacting the sssd socket?
Jakub Hrozek jhrozek@redhat.com hat am 27. September 2019 um 09:55 geschrieben:
On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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?
On Fri, Sep 27, 2019 at 01:05:17PM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 27. September 2019 um 09:55 geschrieben:
On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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?
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@redhat.com hat am 30. September 2019 um 09:23 geschrieben:
On Fri, Sep 27, 2019 at 01:05:17PM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 27. September 2019 um 09:55 geschrieben:
On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
Finally I found the issue, 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
wipe@mailbox.org hat am 27. September 2019 um 13:05 geschrieben:
Jakub Hrozek jhrozek@redhat.com hat am 27. September 2019 um 09:55 geschrieben:
On Fri, Sep 27, 2019 at 09:34:42AM +0200, wipe@mailbox.org wrote:
Jakub Hrozek jhrozek@redhat.com hat am 26. September 2019 um 14:52 geschrieben:
On Tue, Sep 24, 2019 at 01:21:45PM +0200, wipe@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? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
sssd-users@lists.fedorahosted.org