Connection Drops with SMB Servers on macOS Sequoia 15.1

Same. Mac Sequoia 15.1 (which some claimed had fixed the problem) did not. It seems to disconnect during heavy activity for me (copy a large file, for example.) My interim fix was to go back to NFS. Solid as a rock.

Hoping Synology or Apple figure this out. I’d prefer to just be running SMB, since that seems to be the direction everyone is supposed to be going.

No luck for me with 15.1.1.

I updated to 15.1.1 a day or two ago. This evening I switched my connection from NFS back to SMB then started a stress test and lost connection.

Have switched back to using NFS.

I had these same issues. My shares mounted in macOS with no issue however, during file transfer, it would kill my whole network stack. I am talking the transfer would stall after 20 seconds to 2 minutes, then the entire network services on macOS would failover, then NAS share disconnects and transfer failed.

My setup was mounting to some Synology NAS shares (DSM 6 and 7), TrueNAS shares, and just regular old linux box shares.

All other client (non macOS) were rock solid, either via SMB or NFS. macOS clients, absolute garbage with SMB.

I tried all sorts of suggestions and configurations to /etc/nsmb.conf. I tried all manner of permissions and service configurations with DSM and exports. These SMB transfer fails are HEROIC failures with macOS.

What has finally worked for me is the absolute DUMBEST fix for an issue I have come across in my 23+ years of user/admin of such environments.

When authenticating to mount the shares, change one character of your user name to be a CAPITAL letter. For example, if you normally mount with a user name of:

nasuser1

Change the user name to be:

Nasuser1

As far as I can tell, adding a capital to any character in your user name has the same effect.

This 100% fixed my file transfer problems on macOS SMB mounts. All clients.

I do not know if this is an artifact of keychain drift over time, some odd formatting of saved credentials, whatever.

Just in case, I am pasting my nsmb.conf content here if it is useful to anyone. A few things are specific to my environment like forcing SMB 3 and disabling signing (I only mount SMB on shares I own in my own network so I am relatively confident in the authenticity). I absolutely HATE the idea of globally disabling such a security feature as packet signing, but alas, Apple has foisted this on us with poor implements of SMB...but I digress.

nsmb.conf

#Try and use NTFS stream if able
streams=yes

#Soft mount so the system don't flip itself off in a fail
soft=yes

#Remove packet signing because Apple does Apple things with established protocols
signing_required=no

#Disable directory cache
dir_cache_max_cnt=0
dir_cache_max=0
dir_cache_off=yes

#SMB3 Only, change value to 6 if need to support 2 and 3.
protocol_vers_map=4

#Remove other SMB1 features because we do not use SMB1
port445=no_netbios
validate_neg_off=yes

#Do not notify
notify_off=yes

#Do the multichannel if avail
mc_on=yes
mc_prefer_wired=yes

So, in conclusion:

I tried all the nsmb.conf optimizations I came across in hundreds of forum posts. They definitely improved the overall transfer speed when transfers were running, but the connection drops that killed my whole networking services on client were ultimately fixed by adding a capital letter in my username when authenticating.

No clue as to why, but for those that have tried everything else, what have you to lose?

****, thats whacky. Best I could tell my remaining issues once I had a proper conf in place for smb were owing to some stale keychain/passwords/whatever entries I had. The capital letter was just my form of forcing these entries to refresh themselves I guess. Even deleting the entries outright didn't fix it. But once I swapped in the capital letter on username and re-did all of my saved passwords for the shares, it kicked it into gear.

It may be complete coincidence, however. What I can say is bare bones, what seemed to get this working on all my clients was the conf I put above for my use, and forcing all my keychain/passwords saved credentials to refresh for the SMB shares (via deletion, capital letter, resaving the credentials).

Clearly YMMV, but at the end of the day we really need Apple to give us proper SMB if they are going to have SMB. My folks don't buy Mac hardware to futz this deep into protocol configs.

Good luck folks

Sorry to report that the SMB Service update did not help, still experiencing disconnects to my Synology.

Just lost connection, so 15.2 has not fixed the issue with SMB.

For anyone having this issue, this fixed it for me.

Force SMBv3

For Signing

For Synology users, you can do both of these Control Panel > File Services > SMB > Advanced Settings.

In addition to that, you may want to force this in /etc/nsmb.conf on the Mac clients, as others have posted about.

[default]

streams=yes

soft=yes

signing_required=yes

dir_cache_off=no

protocol_vers_map=6

port445=no_netbios

notify_off=yes

mc_prefer_wired=yes

After updating my Mac Studio to Sequoia I've experienced numerous disconnects with my Synology DS1821+ (DSM 7.2.1-69057 update 5). It's been extremely frustrating.

I logged into my Synology this afternoon and saw there's an update to the SMB Service. My installed version is 4.15.13-0877, the update is 4.15.13-2321. There are a lot of fixes listed, though the release notes don't specifically call out Sequoia in any of them. I'm about to install it and do some stress testing - fingers crossed!

The release notes mention this is a Staged Rollout, so you might not see it yet.

eaDir is something to do with search - there mountains of discussion on how to mitigate it. I’ve never bothered with it.

in regards to the DNS entry - it works on mine - not sure where the breakdown would be. If I see something on it - I’ll post back here.

I've discovered another issue with using NFS, this one is not so minor.

It doesn't like directories or filesnames that contain "special" characters like ö. I discovered this when I wrote an Applescript to copy selected tracks out of Music onto an SSD for playback in my Tesla. Tracks from:

• Blue Öyster Cult
• Sinénad O'Connor
• Tiësto featuring BT
• Naïve (album by KMFDM)

all failed to copy. Same things happens with TV shows I have in TV (previously iTunes), such as episodes of Kröd Mändoon - playback fails even though I can see they exist on the Synology.

If I switch the connection from NFS back to SMB the files can seen, but then the disconnection problem returns...

The issue doesn't affect all special characters though, I can watch episodes of Æon Flux without problem.

Initial stress test with 15.2 looks promising, will launch an overnight test and report back.

So I guess you can't edit posts here.

I tried all the nsmb.conf recomendations, usernames with a capital letter, praying to the sun god, etc., but switching from SMB to AFP, and my large file editing flow has been flawless for over 12 hours of continuous operation. On SMB it'd be having issues nearly hourly. I"m using Tdarr to convert viaeo stored on the Synology, so each file is 1-3GB in size. What I noticed is that the SMB connection was dying/getting flakey when tryign to write to the NAS. Synology supposedly fixed that specific bug in a recent SMB package update, but I'm dubious.

I'll share this on their community as well, since I'm sure my NAS is going to nag me about this AFP bit every time I log in, now.

Sequoia 15.2 on a 2024 Mac Mini M4 Pro

Synology DS923+ running DSM 7.2.2-72806 with SMB package version 4.15.13-2321

Of course now DSM is yelling at me about using AFP instead of SMB. I would rather have stability than janky SMB connectivity.

Thanks for the suggestion!

Yesterday afternoon I figured out how to setup NFS and its permissions on the Synology, as well as how to connect from my Studio using NFS.

I then started a stress test, basically running Handbrake with 4 concurrent jobs where the files being read and files being created are on the Synology. When using SMB the connection would drop in under an hour, causing the jobs to abort. This morning the NFS connection is still there and the jobs are still running.

I do have 2 minor issues with using NFS:

For NFS permissions on the Synology I had to use my Studio's IP address instead of hostname. The IP is assigned using DHCP, so could have changed at any time. To prevent that I configured my eero router to reserve the Studio's current IP address.

Each directory now contains a directory called @eaDir, though I don't see them with I'm logged into the Synology and using File Station.