Louis Waweru
2019-Oct-18 11:35 UTC
[Samba] Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
Hello, I have an issue where Macs running a wide range of OS versions all drop connections at seemingly random intervals, but usually after some long period of time less than 24 hours. The Windows clients keep their connections, however. I can test this in PowerShell with a loop like the following: PS C:\Users\louis> while($true) { Add-Content Z:\_smbcheck\windwows-client.txt $DT; Start-Sleep 10; $DT = Get-Date; } This will run endlessly. Similar tests on different Mac clients, all connected to Ethernet on reliable network infrastructure will all fail within hours, and at different times: while sleep 10; do echo "Alive at: `date`" >> /Volumes/data/_smbcheck/macClientServerSigningOff; done while sleep 10; do echo "Alive at: `date`" >> /Volumes/data/_smbcheck/macClientServerSigningOn; done while sleep 10; do echo "Alive at: `date`" >> /Volumes/data/_smbcheck/macClientServerSMB2; done while sleep 10; do echo "Alive at: `date`" >> /Volumes/data/_smbcheck/macClientServerSMB3-Caffeinate; done etc... The Mac computers running these loops range from completely vanilla to having suggested tweaks found here and there. In the logs, the only indication of these events are the following: [2019/10/18 05:27:37.005650, 2] ../source3/smbd/service.c:1050(close_cnum) 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data The Mac clients don't all do this at the same time. It happens completely irregularly and not at fixed intervals. I've tried all the various possibilities in a Mac client's /etc/nsmb.conf to no avail: [default] protocol_vers_map=4 signing_required=no I've set the most power aggressive energy settings, and even used caffeinate <https://github.com/newmarcel/KeepingYouAwake> to make sure the computer was always awake. I've tested a brand new NIC on the server, upgrading firmware on the server, building new versions of samba, reinstalling to Ubuntu 16.04 from 18.04 and upgrading to 18.10 and 19.04 hoping to find a version that didn't have the issue. How can I begin to diagnose this issue, assuming hardware is fine. In summary all hardware tests pass, and after testing with a new NIC, and the fact that Windows clients don't disconnect make me feel like it's a Mac issue, and there are countless threads on the Internet complaining about how Apple implemented SMB, but I'm hoping to learn what these log messages mean: [TimeStamp, 2] ../source3/smbd/service.c:1050(close_cnum) 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data Are they initiated on the client or server side? I am digging for a configuration fix, because there are actually a dozen other servers set up with the same provisioning protocol that don't have the issue. Example: smb.conf file: [global] workgroup = DEPT security = ads realm = DEPT.EXAMPLE.COM ;idmap backend = tdb ;idmap uid = 20000-299999 ;idmap gid = 20000-299999 idmap config DEPT:backend = rid idmap config DEPT:range = 10000-199999 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind refresh tickets = yes winbind offline logon = true winbind expand groups = 1 template homedir = /home/%U template shell = /bin/bash client use spnego = yes client ntlmv2 auth = yes log file = /var/log/samba/samba.log log level = 2 ;obey pam restrictions = yes min protocol = SMB2 client min protocol = SMB2 inherit permissions = yes client ipc signing = auto ;wins support = yes [homes] available = yes comment = Home directories read only = No browseable = No [data] available = yes comment = Main data store for all users path = /data valid users = +DEPT\groupxusers force group = +DEPT\groupxusers writable = yes read only = no Comments in the above show things I have tried enabling and disabling. Higher log levels don't indicate anything before, between, or after: ../source3/smbd/service.c:1050(close_cnum) 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data Many thanks, Louis -- Louis Waweru Senior Staff Associate Department of Psychology 373 Schermerhorn Ext. Columbia University (212) 854-8167 (347) 843-9167
Rowland penny
2019-Oct-18 12:35 UTC
[Samba] Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
On 18/10/2019 12:35, Louis Waweru via samba wrote:> Hello, > > I have an issue where Macs running a wide range of OS versions all drop > connections at seemingly random intervals, but usually after some long > period of time less than 24 hours. The Windows clients keep their > connections, however. > > I can test this in PowerShell with a loop like the following: > PS C:\Users\louis> while($true) { Add-Content > Z:\_smbcheck\windwows-client.txt $DT; Start-Sleep 10; $DT = Get-Date; } > > This will run endlessly. > > Similar tests on different Mac clients, all connected to Ethernet on > reliable network infrastructure will all fail within hours, and at > different times: > while sleep 10; do echo "Alive at: `date`" >> > /Volumes/data/_smbcheck/macClientServerSigningOff; done > > while sleep 10; do echo "Alive at: `date`" >> > /Volumes/data/_smbcheck/macClientServerSigningOn; done > > while sleep 10; do echo "Alive at: `date`" >> > /Volumes/data/_smbcheck/macClientServerSMB2; done > > while sleep 10; do echo "Alive at: `date`" >> > /Volumes/data/_smbcheck/macClientServerSMB3-Caffeinate; done > > etc... > > The Mac computers running these loops range from completely vanilla to > having suggested tweaks found here and there. > > In the logs, the only indication of these events are the following: > > [2019/10/18 05:27:37.005650, 2] ../source3/smbd/service.c:1050(close_cnum) > > 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data > > The Mac clients don't all do this at the same time. It happens completely > irregularly and not at fixed intervals. > > I've tried all the various possibilities in a Mac client's /etc/nsmb.conf > to no avail: > > [default] > > protocol_vers_map=4 > > signing_required=no > > I've set the most power aggressive energy settings, and even used caffeinate > <https://github.com/newmarcel/KeepingYouAwake> to make sure the computer > was always awake. > > I've tested a brand new NIC on the server, upgrading firmware on the > server, building new versions of samba, reinstalling to Ubuntu 16.04 from > 18.04 and upgrading to 18.10 and 19.04 hoping to find a version that didn't > have the issue. > > How can I begin to diagnose this issue, assuming hardware is fine. > > In summary all hardware tests pass, and after testing with a new NIC, and > the fact that Windows clients don't disconnect make me feel like it's a Mac > issue, and there are countless threads on the Internet complaining about > how Apple implemented SMB, but I'm hoping to learn what these log messages > mean: > > [TimeStamp, 2] ../source3/smbd/service.c:1050(close_cnum) > > 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data > > > Are they initiated on the client or server side? > > > I am digging for a configuration fix, because there are actually a dozen > other servers set up with the same provisioning protocol that don't have > the issue. > > > Example: smb.conf file: > > [global] > > workgroup = DEPT > > security = ads > > realm = DEPT.EXAMPLE.COM > > ;idmap backend = tdb > > ;idmap uid = 20000-299999 > > ;idmap gid = 20000-299999 > > idmap config DEPT:backend = rid > > idmap config DEPT:range = 10000-199999 > > winbind enum users = yes > > winbind enum groups = yes > > winbind use default domain = yes > > winbind nested groups = yes > > winbind refresh tickets = yes > > winbind offline logon = true > > winbind expand groups = 1 > > template homedir = /home/%U > > template shell = /bin/bash > > client use spnego = yes > > client ntlmv2 auth = yes > > log file = /var/log/samba/samba.log > > log level = 2 > > ;obey pam restrictions = yes > > min protocol = SMB2 > > client min protocol = SMB2 > > inherit permissions = yes > > client ipc signing = auto > > ;wins support = yes > > > [homes] > > available = yes > > comment = Home directories > > read only = No > > browseable = No > > > [data] > > available = yes > > comment = Main data store for all users > > path = /data > > valid users = +DEPT\groupxusers > > force group = +DEPT\groupxusers > > writable = yes > > read only = no > > > Comments in the above show things I have tried enabling and disabling. > > Higher log levels don't indicate anything before, between, or after: > > ../source3/smbd/service.c:1050(close_cnum) > > 10.11.12.13 (ipv4:10.11.23.13:57939) closed connection to service data > > Many thanks, > Louis >The only problem with your smb.conf is that you haven't set up the 'idmap config lines for the '*' domain, I would add: idmap config * : backend = tdb idmap config * : range = 3000-7999 I do not think this is your problem, I am fairly sure that Samba is only printing that debug message because you have 'log level = 2' in smb.conf and your Mac clients are closing the connections. Rowland
Seemingly Similar Threads
- Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
- Subject=Re: Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
- Subject=Re: Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
- Subject=Re: Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data
- Subject=Re: Mac Clients Disconnect with: source3/smbd/service.c:1050(close_cnum) closed connection to service data