This bug is related to #5941. So the smb.conf (added unique NETBIOS NAME), CTDB settings and software versions are identical to being described in #5941.
Assigning CTDB SMB servers with unique NetBIOS Id resolved #5941. However, now the Windows client can mount only from one CTDB-SMB servers.
When you try to connect to another server you get the following error:
The mapped networked drive could not be created because the following error has occurred:
“The specified network name is no longer available”
Iam unable to use “NetBIOS name” as even though it is listed in network neighbourhood, it does not list the shares when you click. So I use the \\IP-Address\global-share to mount SMB share. We have a round-robin name setup for NAS-head (ctdb-head), but it works only if you happen to chose the right IP address that can be SMB mounted.
When we restart “Winbind” on the server from which Windows client would not mount, it works! But after that when you try to mount from the other server, it fails. So, at a given instance Windows client can only mount from single SMB server in CTDB cluster.
Looking at the “SMB network packets” + SMB + Winbind + CTDB log, I do not find any major error. One thing I see is that, SMB server gets the user-id (TESTDOMAIN\username) when they try to remote mount but after that “client connection seems to shutdown” unless you restart Winbind on the connecting SMB server. I wonder if the client socket parameters/ user credentials gets synced up when you restart Winbind?
Please find all the information you asked for attached. I would like Windows clients to mount from multiple SMB servers controlled by CTDB. Thoughts/advice to resolve this would be appreciated.
Thanks in Advance,
Created attachment 3786 [details]
Network packets snoop at SMB port, log.smb and log.winbind
What we need is a full debug level 10 log of both winbind (all log.wb* files) and smbd, along with your smb.conf
Created attachment 3791 [details]
Initial node1 Winbind/SMB/CTDB log files after CTDB start
Created attachment 3792 [details]
Initial node2 Winbind/SMB/CTDB log files after CTDB restart
Created attachment 3793 [details]
node2 Winbind/SMB/CTDB log file after Windbind restart(only on node2)
Created attachment 3794 [details]
SMB + CTDB configuration
I have attached the Winbind + SMB + CTDB log files with debug level of 10 + necessary CTDB/SMB configuration files.
Windows node were able to mount initially only from node1(192.168.97.5). After Winbind restart on node2(192.168.97.6), Windows node were able to mount from node2 but failed to mount from node1.
Please let me know if you require additional information.
Perusing though the log files, Iam wondering if the issue is due to insufficient UID/GID range and/or winbind unable to properly extract UID from SID. I have specified SMB to use Active Directory RID mapping scheme for
SID --> UID/GID Mapping.
I see the following errors in log.smb on both the nodes at the same instance, but still somehow one node is able to map SID to UID/GID as we can mount from Windows clients.
[2008/12/08 13:46:55, 3] lib/privileges.c:get_privileges(63)
get_privileges: No privileges assigned to SID [S-1-0-0]
get_privileges_for_sids: sid = S-1-1-0
get_privileges: No privileges assigned to SID [S-1-5-32-546]
get_privileges: No privileges assigned to SID [S-1-22-2-99]
winbind failed to find a gid for sid S-1-1-0
Could not convert SID S-1-1-0 to gid, ignoring it
winbind failed to find a gid for sid S-1-5-2
Could not convert SID S-1-5-2 to gid, ignoring it
winbind failed to find a gid for sid S-1-5-32-546
Could not convert SID S-1-5-32-546 to gid, ignoring it
[2008/12/08 13:46:55, 3] groupdb/mapping.c:pdb_create_builtin_alias(786)
pdb_create_builtin_alias: Could not get a gid out of winbind
WARNING: Failed to create BUILTIN\Users group! Can Winbind allocate gids?
Please accept my apologies if the above has nothing to do with the issue and for generating noise.
Created attachment 3806 [details]
CTDB Status and connectivity to SMB daemon
- ctdb status
- ctdb ping -n all
- smbcontrol smbd ping
- ctdb listvars
Migrating to Windows 2003 AD + IDMAP Backend=AD seems to resolve this.