Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

FlorianSchneider

macrumors member
Original poster
Jan 18, 2020
43
8
I have Windows 2008r2 Active Directory server at home with a Solaris 11.4 SMB file server. The Solaris file server has joined the AD domain.

Mounting an SMB share on one of my mac (all running the latest Catalina version) works very well, but after a few hours the share is getting unresponsive and disconnects. This happens only on macOS, other clients running Linux or Windows are not affected.

First I thought it might be a firewall issue and I've placed the macOS client in the same subnet. Didn't help. After a few hours, the share got unresponsive and disconnected.

I've found the an Oracle support document pointing at https://support.apple.com/de-ch/HT208209 . They've claimed, that disabling the .DS_Store would help. Well, it didn't.

The last thing I've tried was mounting a share directly from the windows server and it had exactly the same behaviour. After a few hours the share got again unresponsive and disconnected. This is leading me to the conclusion, that something is wrong on the macOS side.

Did anyone had an issue like this? Any ideas how I can fix this issue?
 
I have Windows 2008r2 Active Directory server at home with a Solaris 11.4 SMB file server. The Solaris file server has joined the AD domain.

Mounting an SMB share on one of my mac (all running the latest Catalina version) works very well, but after a few hours the share is getting unresponsive and disconnects. This happens only on macOS, other clients running Linux or Windows are not affected.

First I thought it might be a firewall issue and I've placed the macOS client in the same subnet. Didn't help. After a few hours, the share got unresponsive and disconnected.

I've found the an Oracle support document pointing at https://support.apple.com/de-ch/HT208209 . They've claimed, that disabling the .DS_Store would help. Well, it didn't.

The last thing I've tried was mounting a share directly from the windows server and it had exactly the same behaviour. After a few hours the share got again unresponsive and disconnected. This is leading me to the conclusion, that something is wrong on the macOS side.

Did anyone had an issue like this? Any ideas how I can fix this issue?
There have been many problems with SMB in Catalina - only the very most recent update got it to work right for me. (There have been many issues where SMB was unreliable unless you connected by IP address instead of server name).

That said, do you know which version of SMB the server is using? Catalina seems unhappy with anything less than SMB3.
 
Sounds like a MacOS SMB configuration setting, as you suggest.
In a terminal, try
Code:
sysctl -a | grep net.smb

My guess is it's one of those _deadtimer parameters. Try setting them to zero, one at a time, to see if you can find teh one that matters. To change these:
Code:
sudo sysctl net.smb.fs.kern_deadtimer=0
etc.

Make a note of their current value before changing; you can just reset these to their previous values the same way if required.
 
Last edited:
That said, do you know which version of SMB the server is using? Catalina seems unhappy with anything less than SMB3.

The server does support SMB version 3.0. Can I somehow verify on macOS which version was used when a connection was established?

My guess is it's one of those _deadtimer parameters. Try setting them to zero, one at a time, to see if you can find teh one that matters. To change these:
Code:
sudo sysctl net.smb.fs.kern_deadtimer=0

Thanks. I will try that.
 
Use smbutil statshares -a

Thanks!

Code:
SERVER_NAME                   xxxxxxxxxxxx
USER_ID                       501
SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
SMB_VERSION                   SMB_3.02
SMB_SHARE_TYPE                DISK
SIGNING_SUPPORTED             TRUE
EXTENDED_SECURITY_SUPPORTED   TRUE
LARGE_FILE_SUPPORTED          TRUE
FILE_IDS_SUPPORTED            TRUE
DFS_SUPPORTED                 TRUE
FILE_LEASING_SUPPORTED        TRUE
MULTI_CREDIT_SUPPORTED        TRUE
PERSISTENT_HANDLES_SUPPORTED  TRUE
ENCRYPTION_SUPPORTED          TRUE

Version 3.0.2. I'd say that looks fine.
 
Thanks!

Code:
SERVER_NAME                   xxxxxxxxxxxx
USER_ID                       501
SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
SMB_VERSION                   SMB_3.02
SMB_SHARE_TYPE                DISK
SIGNING_SUPPORTED             TRUE
EXTENDED_SECURITY_SUPPORTED   TRUE
LARGE_FILE_SUPPORTED          TRUE
FILE_IDS_SUPPORTED            TRUE
DFS_SUPPORTED                 TRUE
FILE_LEASING_SUPPORTED        TRUE
MULTI_CREDIT_SUPPORTED        TRUE
PERSISTENT_HANDLES_SUPPORTED  TRUE
ENCRYPTION_SUPPORTED          TRUE

Version 3.0.2. I'd say that looks fine.
Yep, looks ok. I would next check the timeout settings. But, again, this could just be Catalina being Catalina. It’s not been a smooth smb ride with this version of the OS.
 
Yep, looks ok. I would next check the timeout settings. But, again, this could just be Catalina being Catalina. It’s not been a smooth smb ride with this version of the OS.

I've set the timeout settings as suggested to 0. Now I'm waiting to see if it's fixed. :)
 
Yep, looks ok. I would next check the timeout settings. But, again, this could just be Catalina being Catalina. It’s not been a smooth smb ride with this version of the OS.

I've set the timeout settings as suggested to 0. Now I'm waiting to see if it's fixed. :)
 
As mentioned, I've set net.smb.fs.kern_deadtimer to 0 and mounted then the SMB shares. Well, nothing has changed. After a few hours the shares were disconnected.
 
As mentioned, I've set net.smb.fs.kern_deadtimer to 0 and mounted then the SMB shares. Well, nothing has changed. After a few hours the shares were disconnected.
In a terminal, try
Code:
sysctl -a | grep net.smb
My guess is it's one of those _deadtimer parameters. Try setting them to zero, one at a time, to see if you can find the one that matters. To change these:
Code:
sudo sysctl net.smb.fs.kern_deadtimer=0
etc.

Have you tried the other _deadtimer parameters?
 
They appear to be macos specific implementations of the SMB deadtime parameter (details http://www-sbras.nsc.ru/cgi-bin/www/unix_help/man-cgi?smb.conf+5). Afaik Apple haven't documented them and as such I don't know they differ from each other; as cmaier has already suggested, Catalina has a somewhat 'quirky' implementation of the SMB protocol at the best of times.

Code:
sysctl -a | grep net.smb
net.smb.fs.version: 304400
net.smb.fs.loglevel: 0
net.smb.fs.kern_deadtimer: 60
net.smb.fs.kern_hard_deadtimer: 600
net.smb.fs.kern_soft_deadtimer: 30
net.smb.fs.tcpsndbuf: 8388608
net.smb.fs.tcprcvbuf: 8388608
net.smb.fs.maxwrite: 8388608
net.smb.fs.maxread: 8388608
net.smb.fs.maxsegreadsize: 8388608
net.smb.fs.maxsegwritesize: 8388608

In your OP you asked for ideas as to how to fix your issue. Given that there are only 3 params to try and this was suggested to you several posts ago, i'd suggest simply trying it; if it solves your issue then that's great. If it doesn't its trivial to undo the changes and you can look elsewhere for a solution.
 
After a long time I've started to dig a little bit deeper into it. I've mounted a share directly from the Windows server and one from the Solaris server, while taking a tcpdump. While mainly looking into the SMB protocol, I couldn't really find anything. But I've noticed, that the problems start after 10 hours, which is the default lifetime of a Kerberos ticket and that lead me then the to right path.

I've configured then Kerberos authentication and installed the Kerberos Ticket Autorenewal App from the App Store, which renews the ticket automatically, as soon it expires. And that did the trick. Since then, the SMB share do not unmount itself.

It does seem that macOS is doing something different than Linux or Windows. Even if the machines haven't joined the domain, this issue occured only on macOS. Nevertheless, I'm glad I could fix it finally.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.