8

I have some Ubuntu Servers running Samba with Winbind. Everything is fine, but Macs will randomly disconnect overnight, or at some irregular interval.

On the servers, Samba logs this as two events:

1: ../source3/smbd/service.c:1050(close_cnum)
2: closed connection to service data

By matching timestamps on the Macs I can see they log the drops as:

kcm DEPRECATED USE in libdispatch client: Setting timer interval to 0 requests a 1ns timer, did you mean FOREVER (a one-shot timer)?; set a breakpoint on _dispatch_bug_deprecated to debug

By analyzing timestamps I have determined that this is the only event logged on the Mac clients' side. Here is an example client that has a shell script writing to a text file on a share every ten seconds: Logging Example You can see the connection was alive at 08:59:46 in the text file on the left, and in /var/log/system.log there's only a single relevant message.

I asked on the Samba list serve about it and have been told the Macs are simply closing the connections.


Update:

Wireshark analysis shows some additional information:

Wireshark conversation about SMB error: STATUS_NETWORK_SESSION_EXPIRED Errors from above (Line 4):

  • STATUS_NETWORK_SESSION_EXPIRED
  • SATATUS_INVALID_PARAMETER
  • STATUS_NETWORK_NAME_DELETED

Here is the final SMB2 message (second from bottom): Negotiate Protocol Response: Negotiate Protocol Response

As if to confound, there's an NT Status: STATUS_SUCCESS messages in there (see annotation).

Here is what Microsoft says about the error:

If the Status field in the SMB2 header is STATUS_NETWORK_SESSION_EXPIRED, the client MUST attempt to reauthenticate the session that is identified by the SessionId in the SMB2 header, as specified in section 3.2.4.2.3. If the reauthentication attempt succeeds, the client MUST retry the request that failed with STATUS_NETWORK_SESSION_EXPIRED. If the reauthentication attempt fails, the client MUST fail the operation and terminate the session, as specified in section 3.2.4.23.

Is there a script I can run to just renew the session in a cron job?

End update


Other types clients will keep the connections open forever, so it does indeed seem like only Macs are doing this. The OS versions vary from OS X 10.12 to macOS Catalina, using various flavors of SMB2 to SMB3.

Any idea how I can begin to understand why the macs are doing this, or any tips on getting them to keep the connections alive?

The Mac clients are running jobs that rely on a persistent connection.


Highly relevant to know, but originally left out as I was looking for a workaround:

I have about a dozen of these servers (mostly Ubuntu 18.04; Samba 4.7.6) running fine for the past several years. Three of them had automatic updates installed, and these three have the issue of the Macs disconnecting. I'm holding back letting the other servers restart for the updates, and the Macs will not drop connections to the non-updated servers.

As a test I setup a server to 16.04 to see if and older version of Ubuntu Server would pose the same issue. Surprisingly it has the same problem using a different version of Samba (4.3.11). I will have to do the test again, without letting 16.04 install the latest security updates, in order to confirm my suspicions that those are the cause of the problem.

Though I suspect something in Ubuntu's core changed, I am asking here since only Macs are affected.


On a number of Macs with OSes from 10.12 to Catalina I have tried testing them with their default settings, and all possible combinations of changes to /etc/nsmb.conf:

[default]
signing_required=no
protocol_vers_map=[see manpage for nsmb.conf (linked below)]

manpage for nsmb.conf

I've also tried disabling all sleep and powersaving options, and even using a nice cafffinate wrapper, KeepingYouAwake, to enforce this.

On the server I've tried following the advice of another sysadmin on the #macosx freenode channel, kode54, who shared how they eventually got a stable connection.

The advice didn't help–well I haven't fully tried it as it requires installing a version of Samba from a PPA for a version of Samba maintained by the Linux for Schools Project–but informed me of vfs_fruit and the fact that there is a developmental effort of extending Samba through an extra package for, in part, dealing with Macs. It also led me to find a page on Samba's wiki discussing difficulties with Macs and server-side workarounds: Configure Samba to Work Better with Mac OS X

It's difficult for me to try installing suggested Samba PPA because these servers are fileservers in part only, and are generally always being used for compute jobs that can take days to run (neuroimaging processing). They were built for compute jobs, and do storage almost as a side-effect of the dual-socket, high-memory density, server options also happening to be the servers with the large number of drive bays (16+).

I'm hoping to try other options before becoming fully negatively disruptive.

Since none of the server-side options are helping–I've been trying the flags in various combinations no to avail–I am hoping that the Apple community will have some workaround for me.

Any way of keeping a persistent connection, despite where the issue may originate, would be incredibly valuable.

10
  • Is this something new you're setting up? If not, can you clarify whether this is a new problem, or has it always happened? If it's a new problem, is there anything else that's happened to coincide with when the problem started? Also, how are all of the Macs connecting to the Ubuntu servers? Do they share a connection or...? And do they disconnect at different times or all within a short window of each other? Finally, it's good you're checking the logs - on the Mac side, can you also check to see if there's a familiar pattern in terms of what's going on in the lead up to them disconnecting? – Monomeeth Oct 29 '19 at 3:34
  • @Monomeeth Excellent questions for my vague problem. I intentionally left out a lot of details to avoid complexity, but have now filled them in as you're probably right by suggesting more information is better. – Louis Waweru Oct 29 '19 at 4:16
  • I would ask you for a Wireshark trace. This would allow me to confirm which side is dropping as well as walk through the transactions on the wire to see what's happening at the time of the fault. Logs from the server and client that include the time of failure may also help. You can guess all day and you might get lucky. Logs and network traces will give you a smoking gun, generally. – Wilfred Smith Oct 29 '19 at 21:11
  • Sorry I don’t have a quick answer, but the Wireshark trace and logs should point to something. If you can put them somewhere, I’ll even take a look. – Wilfred Smith Oct 30 '19 at 8:53
  • 1
    Probably spoke too soon. Users are dropping off with the ../source3/smbd/service.c:1050(close_cnum) Samba logs. My connections are still up for some reason (on a vanilla, all defaults, Mac too). – Louis Waweru Nov 2 '19 at 4:22
0

I'd suggest giving a try at the later: https://support.apple.com/en-us/HT202528

Although the use is intended if you'd be using a Mac as file server it nevertheless should provide a higher priority for network I/O on clients.

Read NVRAM settings:

nvram boot-args

Will throw the following error if nvram is set to defaults:

nvram: Error getting variable - 'boot-args': (iokit/common) data was not found

Turn on Server Performance Mode (MacOS 10.11 El Capitan and later):

sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

To turn off either reset PRAM or:

sudo nvram boot-args="$(nvram boot-args 2>/dev/null | sed -e $'s/boot-args\t//;s/serverperfmode=1//')"
-3

You might have solved the problem by now, the only solution which came to my mind with quick-reading your question again is to create a dummy file and using rsync on mac, schedule to transfer that dummy file somewhere over network. This way the network will be kept alive.

2
  • Thanks for the advice. But I've disabled SMB1 on all of my systems in light of the wannacry-like exploits. You are on to something though, I setup a test VM server with SMB1/CIFS, and it doesn't disconnect. Personally, I think Apple just never bothered to keep up with SMB in favor of AFP. But they've recently been updating their implementation, although I still don't think they're doing it correctly. – Louis Waweru Oct 31 '19 at 1:18
  • Since Maverick (MacOS 10.9) Apple announced discontinuing AFP development (deprecated). Thus the native protocol to be used is SMB2 or later. Thus the claim "Mac doesn't support SMB natively is wrong ! – llange Feb 1 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .