From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; FluxWare) Description of problem: I installed a fresh copy of Red Hat 7.3 on our new server and copied the samba config over and the smb and nmb daemons start cleanly. I can access the root of the Samba server (\\servername) and it will display all of the visible shares available. When trying to access any share (visible or not) that has a group in the write list parameter (i.e. @sambausers), from any Window workstation (NT4SP6a, Win2KSP2, Win2K Server SP3) the smbd process associated with that connection hangs. A windows client will hang indefinitely and will spawn more smbd processes. When trying to connect to the share with smbclient, the connection eventually times out with the following error: [root@testbox /tmp]# smbclient //testbox/test -U DOMAIN\\arechenberg added interface ip=10.1.1.35 bcast=10.1.1.255 nmask=255.255.255.0 Password: Domain=[DOMAIN] OS=[Unix] Server=[Samba 2.2.3a] tree connect failed: SUCCESS - 0 Samba is using DOMAIN authentication and if the share is set to 'read only = no' and the write list paramter is removed/commented out, everything works like a charm. This server is using NIS to retrieve user and group information, but the sambausers group is a local group. Version-Release number of selected component (if applicable): samba-client-2.2.3a-6 samba-2.2.3a-6 samba-common-2.2.3a-6 samba-swat-2.2.3a-6 How reproducible: Always Steps to Reproduce: 1. Create share with group in write list 2. Try accessing from Windows box or smbclient 3. Check top for smbd smbd will be one of the top processes and the Windows box will continue to spawn new smbd's. Actual Results: Windows Explorer hangs until smb is restarted. smbclient times out with the above error. Expected Results: Should connect without issues. Additional info: This configuration worked fine on Red Hat 7.1 with samba-2.0.10-2. my smb.conf is below: [global] workgroup = DOMAIN netbios name = CUB01 netbios aliases = cubs server string = CUBS data interfaces = 10.1.1.35 bind interfaces only = Yes security = DOMAIN encrypt passwords = Yes password server = ads02 ads01 restrict anonymous = Yes log file = /var/log/samba/log.%m max log size = 0 announce version = 5.0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 local master = No dns proxy = No wins server = 10.1.1.10 create mask = 0775 force create mode = 0775 directory mask = 0775 force directory mode = 0775 [import] path = /cubs/import write list = @sambausers read only = No browseable = No [export] path = /cubs/export write list = @sambausers read only = No browseable = No [test] path = /cubs/test write list = @sambausers read only = No browseable = No [transactions] path = /cubs/transactions write list = @sambausers read only = no browseable = no
How soon after a bug is submitted should I expect a response?
Depends on the bug. Most often there may not be much response until a developer starts investigating it in detail.
FYI, the most recent samba errata packages did not alleviate my issue. My system now has the follow packages that exhibit the same behavior: samba-common-2.2.7-1.7.3 samba-2.2.7-1.7.3 samba-swat-2.2.7-1.7.3 samba-client-2.2.7-1.7.3
Updating to the most recent errata did not resolve my issue. The current packages installed now are: samba-2.2.7-2.7.3 samba-common-2.2.7-2.7.3 samba-client-2.2.7-2.7.3 samba-swat-2.2.7-2.7.3