We are running samba and winbind on a Redhat Enterprise Linux 3 platform (but samba is compiled by hand). We are authenticating against a large Active Directory (many thousand users and lots of groups). When trying to create a "local user" on our server using the "useradd -u ###" command, the useradd command just hangs. We have specified a range of UID's for winbind to use and I carefully avoid that range when using the "useradd -u ###" command, so I do not think it is a UID conflict. It works when the winbind service is stopped, but that hardly seems a satisfactory solution (especially as we need to keep the samba/winbind service up as much as possible).
replease retest against 3.0.11 and repoen if the problem still exists. You may need to applthe winbind_find_dc patch at http://samba.org/~jerry/patches/post-3.0.11/ as well. Thanks.
We have upgraded to Samba 3.0.15pre2 but the problem still persists. The problem also manifests itself when trying to add a local group. Any other information or things I can try would be appreciated.
Here is some additional information. We tried to add a local group after turning off the winbind service. It seems that the the tdb files got corrupted somehow after the local user/group was added. winbind was having problems resolving SID to gid. We deleted all the cache files, did a clean installation (we were using 3.0.13 when the problem started) but the problem persisted. Then I downloaded the 3.15pre version and that seemed to resolve the issue. However, the error messages were not consistent during this process. Right after restarting smbd and winbindd, these errors showed up: *could not lookup sid* (log.winbindd) * standard input is not a socket, assuming -D option * (log.smbd) * getpeername failed. Error was Transport endpoint is not connected* (log.smbd) (this error is still in the 3.0.15 version) wbinfo -t returns success. getent groups|grep 'groupname' returns a group with username. However, 'groups username' returns user doesn't exists. One time I got these error instead of the above: *id: cannot find name for group ID xxxxxx*
please retest against 3.0.20a (the current SAMBA_3_0_RELEASE branch) which will publically be availebl next week.
I compiled the source for 3.20a on a RedHat Enterprise Linux 3 platform and the problem persists. After starting the samba and winbind services I type "useradd -u 1234 test1234" and the command never comes back (see my original description in https://bugzilla.samba.org/show_bug.cgi?id=2173#c0). Any suggestions of things I can try to provide more information are welcome.
In https://bugzilla.samba.org/show_bug.cgi?id=2173#c5 I meant "version 3.0.20a".
Can you try setting 'winbind enum users = no' and 'winbind enum groups = no'. Then run strace on the useradd command to see where the hang is. Might give some clues.
Created attachment 1506 [details] strace output when running useradd (no user or group enums) This is the strace output from the command: "strace -ostrace.out /usr/sbin/useradd -u 603 test333" with samba and winbind (version 3.0.20a) running and with the settings "winbind enum users = no" and "winbind enum groups = no" in the smb.conf file. This is running on Linux RHEL 3.
Running useradd with 'winbind enum users = no' and 'winbind enum groups = no' _does_ work around the problem. Unfortunately, we need to be able to see the user and group names when doing things like "ls -l". Also, it is not feasible for us to shutdown the samba server to add new local users. Anyway, I have created an strace output as requested and uploaded it as an attachment (https://bugzilla.samba.org/attachment.cgi?id=1506&action=view). I hope it will help shed some light on the problem.
Actually setting 'winbind enum {users,group] = no' should not effect ls -l. It simple disable the get{pw,gr}ent(), not get{pw,gr}name(), et. al. This might break things like id or finger. But ls, chown, etc...should be fine unless they are really badly written to begin with. You can test this with "getent passwd 'domain\user'". That should still work even though 'getent passwd' does not retun domain users. So if turning off enumerating solves the problem, that is an acceptable work around I think.
(In reply to comment #10) > Actually setting 'winbind enum {users,group] = no' should not > effect ls -l. It simple disable the get{pw,gr}ent(), not > get{pw,gr}name(), et. al. This might break things like id > or finger. But ls, chown, etc...should be fine unless they > are really badly written to begin with. > > You can test this with "getent passwd 'domain\user'". That should still work > even though 'getent passwd' does not retun domain users. > > So if turning off enumerating solves the problem, that is an > acceptable work around I think. I guess I will use this as a work-around. However, as the one of the goals of sambs is to be "... an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients." this issue needs to be addressed at some point. After all, my Windows 2000 client has no problem dealing with the AD, even one as large the one we have.
Your sarcasm is not appreciated. Windows user a group enumeration is basically broken via rpc in the newer MS hotfixes anyways. By default, Windows does attempt to enumerate users or groups. Note the search box changes in Windows 2000 when dealing with AD. However, we are working on upcoming changes. What you don't describe is what turning off enumeration breaks. You are basically whining without giving me any helpful information. If we make 'winbindd enum users = no' the default and things just work, is that seamless enough for you?
(In reply to comment #12) > Your sarcasm is not appreciated. > > Windows user a group enumeration is basically broken > via rpc in the newer MS hotfixes anyways. By default, > Windows does attempt to enumerate users or groups. Note > the search box changes in Windows 2000 when dealing > with AD. > > However, we are working on upcoming changes. > > What you don't describe is what turning off enumeration breaks. > You are basically whining without giving me any helpful > information. If we make 'winbindd enum users = no' the default > and things just work, is that seamless enough for you? > > > > > I was not being sarcastic. I just wanted to be sure that a shortcoming of an excellent project will not go unaddressed. But I guess you are a mind reader (THAT is sarcasm).
hahah :-) Touche. :-) OK. So I let my cynical side show. Point well taken. You still didn't answer the question abotu what breaks when disabling enumeration. The reason I ask is that we are considering disabling enumeration via get{pw,gr}ent() in a future release.