Hello all,
I am experiencing strange behaviour of some of my NFS clients running SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID' mapping on files on an NFS share, see this example: --------------- $ l -d SOMEFOLDER drwxrwxr-x 17 root 4294967294 4096 Nov 6 15:31 SOMEFOLDER/ $ stat SOMEFOLDER File: ‘SOMEFOLDER’ Size: 4096 Blocks: 8 IO Block: 65536 directory Device: 26h/38d Inode: 27258 Links: 17 Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: (4294967294/ UNKNOWN) ... --------------- Also all files SOMEFOLDER/* are affected.
I know the group the folder is supposed to have is set correctly and other clients show its name. Also, users who are in the missing group show the groupname and GID just fine when doing an 'id USERNAME'.
Restarting SSSD resolves the issue for some time.
My SSSD config is as follows: --------------- [sssd] config_file_version = 2 services = nss,pam domains = default [nss] filter_groups = root filter_users = root [pam] [domain/default] id_provider = ad auth_provider = ad access_provider = simple chpass_provider = ad ad_domain = ... ad_enable_gc = False ldap_id_mapping = False enumerate = False ignore_group_members = True dyndns_update = False cache_credentials = True ldap_search_base = ... ldap_user_search_base = ... ldap_group_search_base = ... ldap_user_search_scope = one ldap_group_search_scope = one krb5_ccachedir = /run/user/%U krb5_ccname_template = DIR:%d/krb5cc override_homedir = ... simple_allow_groups = ... ---------------
Is this a known problem with 1.12.1? I will test with 1.12.2 soon, but as the problem only appears randomly, I thought I'd already ask now...
Best regards, J Brauchle
On Mon, 10 Nov 2014, Joschi Brauchle wrote:
I am experiencing strange behaviour of some of my NFS clients running SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID' mapping on files on an NFS share, see this example:
What version of nfs-utils?
jh
On 11/10/2014 05:27 PM, John Hodrien wrote:
On Mon, 10 Nov 2014, Joschi Brauchle wrote:
I am experiencing strange behaviour of some of my NFS clients running SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID' mapping on files on an NFS share, see this example:
What version of nfs-utils?
jh
The affected machine has this: # zypper if nfs-client|grep -i version Version: 1.3.0-4.2.1
I have not tested local files at all, as the machine is solely used as an NFS client. Thus I can't guarantee that it is only NFS related...
On Mon, Nov 10, 2014 at 05:24:52PM +0100, Joschi Brauchle wrote:
Hello all,
I am experiencing strange behaviour of some of my NFS clients running SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID' mapping on files on an NFS share, see this example:
$ l -d SOMEFOLDER drwxrwxr-x 17 root 4294967294 4096 Nov 6 15:31 SOMEFOLDER/ $ stat SOMEFOLDER File: ‘SOMEFOLDER’ Size: 4096 Blocks: 8 IO Block: 65536 directory Device: 26h/38d Inode: 27258 Links: 17 Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: (4294967294/ UNKNOWN) ...
Also all files SOMEFOLDER/* are affected.
I know the group the folder is supposed to have is set correctly and other clients show its name. Also, users who are in the missing group show the groupname and GID just fine when doing an 'id USERNAME'.
This sounds similar to the issue Sergey Urushkin had reported to sssd-users earlier today.
At the same time, I wonder why the GID is being reported as 4294967294, isn't that nfsnobody or a similar 'fallback' user?
Restarting SSSD resolves the issue for some time.
My SSSD config is as follows:
[sssd] config_file_version = 2 services = nss,pam domains = default [nss] filter_groups = root filter_users = root [pam] [domain/default] id_provider = ad auth_provider = ad access_provider = simple chpass_provider = ad ad_domain = ... ad_enable_gc = False ldap_id_mapping = False enumerate = False ignore_group_members = True dyndns_update = False cache_credentials = True ldap_search_base = ... ldap_user_search_base = ... ldap_group_search_base = ... ldap_user_search_scope = one ldap_group_search_scope = one krb5_ccachedir = /run/user/%U krb5_ccname_template = DIR:%d/krb5cc override_homedir = ... simple_allow_groups = ...
Is this a known problem with 1.12.1? I will test with 1.12.2 soon, but as the problem only appears randomly, I thought I'd already ask now...
Best regards, J Brauchle
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 10 Nov 2014, Jakub Hrozek wrote:
At the same time, I wonder why the GID is being reported as 4294967294, isn't that nfsnobody or a similar 'fallback' user?
If rpcidmapd can't work it out, it'll fall back to a nobody user.
In my case I saw this linked to BZ#1033708, which wasn't SSSD's fault.
jh
On 11/10/2014 05:24 PM, Joschi Brauchle wrote:
Hello all,
I am experiencing strange behaviour of some of my NFS clients running SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID' mapping on files on an NFS share, see this example:
$ l -d SOMEFOLDER drwxrwxr-x 17 root 4294967294 4096 Nov 6 15:31 SOMEFOLDER/ $ stat SOMEFOLDER File: ‘SOMEFOLDER’ Size: 4096 Blocks: 8 IO Block: 65536 directory Device: 26h/38d Inode: 27258 Links: 17 Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: (4294967294/ UNKNOWN) ...
Also all files SOMEFOLDER/* are affected.
I know the group the folder is supposed to have is set correctly and other clients show its name. Also, users who are in the missing group show the groupname and GID just fine when doing an 'id USERNAME'.
Restarting SSSD resolves the issue for some time.
Correction: This is not true! Restarting SSSD or clearing user and group cache does not help.
So looks like NFS problem!
On Mon, 10 Nov 2014, Joschi Brauchle wrote:
Correction: This is not true! Restarting SSSD or clearing user and group cache does not help.
So looks like NFS problem!
Which is the one thing that made it not like my problem. Does:
nfsidmap -c
clear it (although not necessarily what seems to be instantly)?
jh
Which is the one thing that made it not like my problem. Does:
nfsidmap -c
clear it (although not necessarily what seems to be instantly)?
jh
Unfortunately I get this: # nfsidmap -c nfsidmap: fopen(/proc/keys) failed: No such file or directory
(this looks like another bug)
and killing and restaring rpc.idmapd does not fix the problem.
On 11/10/2014 05:47 PM, Joschi Brauchle wrote:
# nfsidmap -c nfsidmap: fopen(/proc/keys) failed: No such file or directory
Just FYI: I have reported the issue here http://bugzilla.opensuse.org/show_bug.cgi?id=904717
It looks like the default maximum of keys (200) too small for nfsv4 id mapping, see: https://bugs.mageia.org/show_bug.cgi?id=11120
The workaround given there fixes the problem.
Thanks for everyones help! This is clearly not an SSSD problem...
On Mon, Nov 10, 2014 at 06:17:31PM +0100, Joschi Brauchle wrote:
On 11/10/2014 05:47 PM, Joschi Brauchle wrote:
# nfsidmap -c nfsidmap: fopen(/proc/keys) failed: No such file or directory
Just FYI: I have reported the issue here http://bugzilla.opensuse.org/show_bug.cgi?id=904717
It looks like the default maximum of keys (200) too small for nfsv4 id mapping, see: https://bugs.mageia.org/show_bug.cgi?id=11120
The workaround given there fixes the problem.
Thanks for everyones help! This is clearly not an SSSD problem...
Thanks for reporting back the root cause of the issue!
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Joschi Brauchle