10:24 a.m.
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
10:27 a.m.
New subject: Client randomly losing GID information on NFS files w/ 1.12.1
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
10:30 a.m.
New subject: Client randomly losing GID information on NFS files w/ 1.12.1
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...
10:31 a.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
10:35 a.m.
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
10:35 a.m.
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!
10:36 a.m.
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
10:47 a.m.
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.
11:17 a.m.
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...
1:37 p.m.
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!
3448
days inactive
3448
days old
sssd-users@lists.fedorahosted.org
9 comments
3 participants
participants (3)
-
Jakub Hrozek -
John Hodrien -
Joschi Brauchle