Mac clients - SMB cache issues

[HappyDays]

I'm guessing that's the nsmb.conf on the NAS? I don't see unix extensions or veto files when man nsmb.conf on macOS.

In DSM's Help it says using the Veto Files feature can impact performance. Maybe if you add screenshots of your File Sharing and SMB Advanced settings then we can compare them against ours. I've not noticed these issues and I have a DSM shared folder permanently mounted in Finder: it is used exactly as I used the USB drive that this replaces... create, modify, and hold media files and libraries.

I'm also on the latest DSM 7.1.1 and it's latest SMB Service. So I think the same as you. Using Ventura on main Mac and Big Sur on old MacBook. I have scheduled uploads from Mac to NAS using CCC 6, which auto-mounts other shares using SMB.

No, it's the nsmb.conf on the Mac.

Much of the contents came from a previous post from a good while ago on the old Synology user forum. I can't remember the exact details of the research I then went through at the time as it was a good few years ago, but I have now removed those two lines you mention from the file.

There was until VERY recently an Apple support page that gave an nsmb.conf file to use on Mac clients to Synology servers, but it now seems to have mysteriously disappeared, or at least I can't find it any more.

The best settings to use on a Mac accessing a Synology SMB share is a very arcane subject and there are lots of recommendations floating around. I had tried to distil these into a suitable file but like any tweaks I am sure it could always be improved.

One thing I have seen reference to (in Synology Community) is that this cache issue can arise because there are accesses to the share using multiple SMB versions, causing the cache to get "confused". I don't know the truth of this, but maybe it is the cause. At least I know that I am not the only one experiencing the cache issue. I have, as you can see, added the protocol_vers string to my nsmb.conf file (at the prompting of Telos above) so maybe that will resolve the issue.

I will post my new nsmb.conf which (following some research) I have annotated to try and make the purpose of the specific strings clearer.

You will see that I have disabled the multichannel and wired network settings as both of these are irrelevant for me (and I think most people) as I don't have a multichannel connection from my Mac to the network. I believe that this would only be valid for a Mac Pro anyway which could have multiple network ports installed. I am pretty sure that it would not make sense to use a wired and a wireless connection as the two channels giving the asymmetry (and variability) of throughput, and the general flakiness of wireless connections which IMHV are not really suitable for connections to a file server.

I don't want to take us down a rabbit hole, but it further seems to me that multichannel has only very limited utility and unless there is only one client it should not be used - at present I have the two ports on my DS420+ along with the relevant ports on the ethernet switch aggregated, which has benefits for throughput to the network and failover between the ports. However I do not think it is appropriate to use SMB Multichannel on the server because it needs two ports all the way through between the server and the client and is designed for a single client only. My bet is that there will be lots of people who switch it on not knowing of its limited application.

[default]

# Revised 2023-05-11

# Disable packet signing to improve performance as no security issue on secure (non-infiltrated) network.
# Note this is off by default from macOS 10.13.4 onwards although this is ambiguous (Apple HT205926)
signing_required=no

# Use NTFS streams if supported (Macs use two streams per file - ADS or "multi-fork")
streams=yes

# Soft mount by default (doesn't keep trying to access share so hanging the client)
soft=yes

# Disable directory caching (ensures Finder folder contents display is up to date)
dir_cache_off=yes

# Turn off change notifications (Finder maintains folder list integrity)
notify_off=yes

# Disable NetBIOS because not using SMB 1
port445=no_netbios

# Ensure desired SMB level and prevent SMB 1 (Apple HT211927)
# 1 - SMB 1 only
# 2 - SMB 2 only
# 3 - SMB 1 or 2
# 4 - SMB 3 only (my choice)
# 6 - SMB 2 or 3 (recommended)
# 7 - SMB 1 or 2 or 3 (Apple default)
protocol_vers_map=4

# SMB Multichannel behaviour (Apple HT212277)
# Disable multichannel support because only one wired network connection
# mc_on=no

# Prefer wired network (multichannel only) (Apple HT212277)
# mc_prefer_wired=yes

 

[Robbie]

My macOS nsmb configuration for a Mac that uses wifi:

rob@MBP-Rob ~ % cat /etc/nsmb.conf
[default]
# /etc/nsmb.conf - macOS 11.3+
#------------------------------------------------------------------------------
# SMB configuration for macOS 11.3+ <-> Synology
#------------------------------------------------------------------------------
# Additional information:
# -----------------------
# https://support.apple.com/de-de/HT211927
# https://support.apple.com/en-us/HT208209
# https://apple.stackexchange.com/questions/309016/smb-share-deadlocks-since-high-sierra
# https://photographylife.com/afp-vs-nfs-vs-smb-performance
# https://support.apple.com/de-de/HT212277
#------------------------------------------------------------------------------

# Use NTFS streams if supported
# streams=yes

# Set hard or soft mount of shares
# Hard mount: a request is issued repeatedly until the request is satisfied
# Soft mount: tried until completed, the retry limit is met or the timeout limit is met
# Soft mount by default
soft=yes

# Disable signing, this became default in later macOS versions
signing_required=no

# Disable directory caching
dir_cache_off=yes

# Disable local SMB caching
# Can be set and then unset to clear SMB cache
dir_cache_max_cnt=0

# Lock negotiation to SMB2/3 only
# 7 == 0111  SMB 1/2/3 should be enabled
# 6 == 0110  SMB 2/3 should be enabled
# 4 == 0100  SMB 3 should be enabled
protocol_vers_map=6

# No SMB1 = no NetBIOS (WINS) and it should be disabled
port445=no_netbios

# Turn off notifications
# notify_off=yes

# Prefer wired networks over Wi-Fi networks that may advertise faster speeds than appropriate
mc_prefer_wired=yes

# Remember, after editing and saving with VI, to log out of macOS account and log back in again for the new settings to load
rob@MBP-Rob ~ %

On one of my NASes (with 1 x 10GbE link):

Rob@Rivendell:~$ cat /etc/samba/smb.conf
# Copyright (c) 2000-2019 Synology Inc. All rights reserved.
# Whatever...
# IMPORTANT: Synology will not provide technical support for any issues
#            caused by unauthorized modification to the configuration.

[global]
    printcap name=cups
    winbind enum groups=yes
    include=/var/tmp/nginx/smb.netbios.aliases.conf
    encrypt passwords=yes
    min protocol=SMB2_10
    security=user
    local master=no
    realm=*
    passdb backend=smbpasswd
    printing=cups
    max protocol=SMB3
    winbind enum users=yes
    load printers=yes
    workgroup=WORKGROUP
Rob@Rivendell:~$

️

 

[fredbert]

My macs have been migrated over many Mac OS X / macOS versions and I wonder if that is why I don't recognise the nsmb.conf files you both have.

My Mac Mini running Ventura. I think I created this a while ago to disable signing_required. I do use SMB multichannel with two wired Ethernet ports to the NAS (it has LAG on Ports 1+2+3, and a single connection on Port 4).

[default]
protocol_vers_map=6
signing_required=no
mc_prefer_wired=yes

I checked what is defaulted using man nsmb.conf and notice you have some keywords that aren't in here.

The SMB library uses the following information for section names:

     A)      [default]
     B)      [SERVER]
     C)      [SERVER:SHARE]

     Possible keywords may include:

     Keyword                 Section        Default    Comment
                             A B C      Values
     addr                    - + -                         DNS name or IP address of server
     nbtimeout               + + -          1s             Timeout for resolving a NetBIOS name
     minauth                 + + -          NTLMv2         Minimum authentication level allowed
     port445                 + + -          both           How to use SMB TCP/UDP ports
     streams                 + + +          yes            Use NTFS Streams if server supported
     soft                    + + +          no             Force all mounts to be soft
     notify_off              + + +          no             Turn off using notifications
     kloglevel               + - -          0              Turn on smb kernel logging
     protocol_vers_map       + - -          7              Bitmap of SMB Versions that are enabled
     signing_required        + - -          no             Turn on smb client signing
     signing_req_vers        + - -          6              Bitmap of SMB Versions that have signing required
     validate_neg_off        + - -          no             Turn off using validate negotiate
     max_resp_timeout        + + -          30s            Max time to wait for any response from server
     submounts_off           + + +          no             Turn off using submounts
     dir_cache_async_cnt     + + -          10             Max async queries to fill dir cache
     dir_cache_max           + + -          60s            Max time to cache for a dir
     dir_cache_min           + + -          30s            Min time to cache for a dir
     max_dirs_cached         + + -          Varies         Varies from 200-300 depending on RAM amount
     max_cached_per_dir      + + -          Varies         Varies from 2000-10000 depending on RAM amount
     netBIOS_before_DNS      + + +          no             Try NetBIOS resolution before DNS resolution
     mc_on                   + - -          yes            Turn on SMB multichannel (allow more than one channel per session)
     mc_prefer_wired         + - -          no             Prefer wired NIC's over wireless in multichannel mode
     encrypt_cipher_map      + - -          15             Bitmap of SMB 3.1.1 encryption algorithms that are enabled
     force_sess_encrypt      + - -          no             Force session encryption for all mounts
     force_share_encrypt     + - -          no             Force share encryption for all mounts

My DS1520+, which I have both local DSM and LDAP users (hence the various LDAP-y lines), but otherwise looks pretty similar to the above NAS ones.

[global]
    printcap name=cups
    winbind enum groups=yes
    include=/var/tmp/nginx/smb.netbios.aliases.conf
    ldap admin dn=uid=myadminuser,cn=users,dc=mydomain,dc=tld
    encrypt passwords=yes
    min protocol=SMB2
    ldap ssl=start tls
    security=user
    local master=no
    realm=*
    ldap passwd sync=yes
    ldap suffix=dc=mydomain,dc=tld
    passdb backend=multi:smbpasswd,ldapsam:ldap://127.0.0.1
    syno ldap support=yes
    printing=cups
    max protocol=SMB3
    winbind enum users=yes
    load printers=yes
    workgroup=WORKGROUP

 

[HappyDays]

@Robbie: Thanks - I may try playing with the smb.conf although I have avoided doing so yet as I have assumed that the standard settings must be OK as many people don't have any issues.

One thing which my research led to was that the mc_prefer_wired setting only seems to have any effect if you also have multichannel implemented on the client, which for the reasons I mentioned seems unlikely to be of use. I think the giveaway is that the string starts with mc which obviously means multichannel.

-- post merged: 12. May 2023 --

@fredbert. Thanks - this is all such a minefield.

The one keyword which is in my version of the nsmb.conf which has been widely recommended in the past, but is not mentioned in the man page, is dir_cache_off=yes. In fact the Apple support page that used to suggest setting it this way in nsmb.conf, HT208209, no longer does so but instead recommends changing a setting DSDontWriteNetworkStores to True in the Terminal. The dir_cache_off keyword may be an undocumented setting which may have the same effect (although this is not clear to me from the description) - whatever the case I will try removing it from my nsmb.conf file and see what effect it has.

You mention that you use multichannel (which obviously defaults to on) but I wondered how you had two RJ45s on your Mac Mini - maybe a dongle for the second one?

 

[fredbert]

You mention that you use multichannel (which obviously defaults to on) but I wondered how you had two RJ45s on your Mac Mini - maybe a dongle for the second one?

I have two Apple adapters: Thunderbolt 3 to 2 and Thunderbolt [1] to Gigabit Ethernet. This gives me a second Ethernet interface to the builtin 10GbE. The annoying thing with [Apple's?] multichannel is that it matches client ports to server ports, so the single 10 GbE won't connect to two 1 GbE NAS ports. I might be reading it wrong that this is one way it should work but I can only get the Mac's wired 1 + 10 GbE ports to connect to separate 1 GbE connections on the NAS. And definitely cannot get Mac WiFi to be active in multichannel with the wire port, even when it's link rate is 1200 Mbps or even higher.

I already had the Ethernet adapter for my old MacBook Air. Then got the TB3-2 adapter to speed up migration between our old Mac Minis to new M1s. And I already had the Thunderbolt cable from helping someone resurrect a MacBook using Target Disk Mode.

 

[HappyDays]

I imagine that the two ethernet ports would need to be matched for multichannel to kick in. Otherwise maybe one port will potentially be continuously buffering because of the mismatch. But I am not claiming to be an expert as I don't have need for that sort of high speed network connection, I just need it to work without stalling!

For multichannel to work on one ethernet adapter it seems that it needs to support RSS (Receive Side Scaling) and I haven't found any mention of whether Mac ethernet adapters do, although you might know more about this. Here is the Synology page about it:

Synology Knowledge Center - Deploying SMB3 Multichannel

 

[HappyDays]

There is an interesting page on Apple Support numbered HT212277, "Configure SMB Multichannel behavior", which is as always not entirely clear in what it says. Why doesn't someone read this things to make sure they are totally clear and unambiguous?

It says "SMB Multichannel allows macOS to establish more than one connection to an SMB server, increase transfer speeds, and provide redundancy. The server must support SMB Multichannel to use any of these features. To enable redundancy, you should enable more than one network connection that allows connectivity to the SMB server. When SMB Multichannel is enabled, and more than one network is available, macOS prefers the network that advertises itself to be the fastest. For macOS to use multiple connections simultaneously for faster transfer rates, the interfaces must have the same speeds enabled."

The most unhelpful sentence is the second to last, "When SMB multichannel is enabled...". I suspect this is basically saying that if there are two network connections (I think the word connections is missing from both uses of the word network in this sentence), and they are different speeds, macOS cannot utilise them together for multichannel, essentially because it is configured to preferentially favour the fastest connection in that scenario.

In my view that sentence would be better deleted as the paragraph makes sense without it. It could be added as a bit of additional information to explain why multichannel doesn't work with two connections of different speeds, in which case maybe it should be the last sentence in the paragraph, possible even in brackets.

What it doesn't really begin to address is the other questions about the ethernet connections - such as whether the Mac ethernet implementation supports RSS (my guess is not as maybe they would have mentioned it here). Furthermore because the number of Macs that natively support multiple ethernet interfaces is very limited, I would have thought that the implementation issues for the bulk of systems out there should really be addressed here - do USB ethernet dongles simply work if they are the same speed as the built-in interface, or are there any driver issues?

Incidentally one thing which I have long suspected as maybe one of the reasons a connection to a server can drop is when your Mac has both ethernet and WiFi connections in use (with different IP addresses) and the Mac switches from preferring its ethernet connection to its WiFi connection.

I am not sure how a Synology box would handle the client IP address suddenly changing - how exactly would it manage this? Does it ignore the IP address and just use the username to identify transactions? Certainly if you look at the Synology widget showing the logged-in users the IP address is detailed next to the username, so it seems like there is a link between the connection and the IP address.

Maybe macOS automatically and persistently routes all traffic to the server through the interface (and its IP address) which was used when the connection to the server was established - but maybe not?

 

[Robbie]

All my Macs have native ethernet ports, with the exception of laptops.

For 1 GbE they all use good NICs, typically Broadcom. As an example my M1 Mac minis have Broadcom 57762-A0, so has the full suite of modern NIC capabilities, including RSS capability.

For my 10 GbE capable Macs Apple seems to favour the Marvell AQC113 NIC, so again the full suit of capabilities (although I think RSS with fragmented or UDP packets may be a no-go?).

As to how Apple uses everything... well good luck finding that written down!

For macOS users, if you want to get into the weeds of network and NIC management then use the Terminal command networksetup.

️

 

[anthony11]

Some notes, since people can and do find older threads:

• On the Synology side, one can force / restrict the network interface to use by editing the avahi config. Note that this may need to be repeated after every reboot.
• Synology appears to have removed WiFi support, which is a royal PITA. I need mine to be available on my home network so that TVs, Amazon sticks, etc. can reach Plex, so I had to run CAT6A to my wireless router/access point for the default route.
• I also need faster performance on my desktop, so I added a 10GE NIC to the Synology, connected directly to my Mac Studio with a separate RFC1918 subnet. Hence the need for the above dance. Someone above said something about only Mac Pros having multiple interfaces, this is false. There are various USB and Thunderbolt adapters out there.
• You don't have to use vi on the macOS side.

 

[Robbie]

Some notes, since people can and do find older threads:

• Someone above said something about only Mac Pros having multiple interfaces, this is false. There are various USB and Thunderbolt adapters out there.

Ahem, what is false here?

• The Mac Pro does have 2 wired network connections
• All other Macs have a maximum of 1 wired network connection
• Purchasing additional 3rd-party network interfaces is just a way of overcoming the stated limitations

So no, I will not claim that my Mac Studio has 9 wired network interfaces - it has just 1.

️

 

[HappyDays]

Some notes, since people can and do find older threads:

• On the Synology side, one can force / restrict the network interface to use by editing the avahi config. Note that this may need to be repeated after every reboot.
• Synology appears to have removed WiFi support, which is a royal PITA. I need mine to be available on my home network so that TVs, Amazon sticks, etc. can reach Plex, so I had to run CAT6A to my wireless router/access point for the default route.
• I also need faster performance on my desktop, so I added a 10GE NIC to the Synology, connected directly to my Mac Studio with a separate RFC1918 subnet. Hence the need for the above dance. Someone above said something about only Mac Pros having multiple interfaces, this is false. There are various USB and Thunderbolt adapters out there.
• You don't have to use vi on the macOS side.

Regarding your second point - how does the Synology box know that a connection from a client device to the LAN is over WiFi rather than wired? Surely this is not evident - it is just a device on the LAN? Unless I am missing your point.

Regarding your third point - yes, there are various ways of adding ethernet connections in additions to the built-in wired port(s). When I said "the number of Macs that natively support multiple ethernet interfaces is very limited" I was referring to interfaces built in to the Macs ("natively" - maybe I should have been more explicit).

My point was that we don't know whether the various dongle/add-on devices support RSS so that they can be used as part of an SMB Multichannel connection. I may be wrong about this, but I have not seen this specified for the various devices you can purchase.

 

[Robbie]

@HappyDays
I think he was just referring to a Synology being used wirelessly via a USB dongle on the NAS itself.

In any case, SMB servers/clients will know if a LAN participant is using WiFi or a wired connection as it is flagged as part of the protocol (which also includes the current connection speed over wifi); this is also used as part of the scoring system to decide which interface connection to use.

SMB MC is designed to work with near-identical network settings on each MC network interface. WiFi is very different to wired traffic on a LAN as it is inherently simplex, has extra headers for the wireless segment, contains extra data, has increased frame spacing plus it adds additional overhead for some protocols (eg UDP, which is simply broadcast blind on a wired segment but requires an ACK on a wireless link). Plus you get all the wifi specific meta data (information elements), beacons and alike.

A typical SMB MC client/server exchange with mixed wired & wifi will look something like:

rob@Mac-Studio ~ % smbutil multichannel -a
Session: /Volumes/Mac mini SSD
Info: Setup Time: 2023-08-07 12:46:13, Multichannel ON: no, Reconnect Count: 0
    Total RX Bytes: 59662492, Total TX Bytes: 35149800
       id         client IF             server IF   state                     server ip                 port   speed
========================================================================================================================
M     264     N/A                          N/A      [session active       ]   10.0.1.16                 445    N/A

Session: /Volumes/Spare Shared Folder 1-2
Info: Setup Time: 2023-08-07 12:48:32, Multichannel ON: yes, Reconnect Count: 0
    Total RX Bytes: 100696, Total TX Bytes: 80610
       id         client IF             server IF   state                     server ip                 port   speed
========================================================================================================================
M     265  en0    (Ethernet)  18         4          [session active       ]   10.0.1.42                 445    1.0 Gb
ALT   266  en1    (wifi    )  17         2          [session inactive     ]   2a02:....                    445    201.7 Mb
Server NIC:
    name: NA, idx: 2, type:    NA, speed 1.0 Gb, state connected
        ip_addr: 2a02:....
        ip_addr: 2a02:....
        ip_addr: fd83:....
        ip_addr: fd8d:....
        ip_addr: 10.0.1.43
Server NIC:
    name: NA, idx: 4, type:    NA, speed 1.0 Gb, state connected
        ip_addr: 2a02:....
        ip_addr: 2a02:....
        ip_addr: fd83:....
        ip_addr: fd8d:....
        ip_addr: 10.0.1.42
Client NIC:
    name: en0, idx: 18, type: wired, speed 10.0 Gb, state connected
        ip_addr: fd8d:....
        ip_addr: 2a02:....
        ip_addr: fd83:....
        ip_addr: 2a02:....
        ip_addr: 2a02:....
        ip_addr: 10.0.1.14
        ip_addr: fe80:....
Client NIC:
    name: en1, idx: 17, type: wireless, speed 201.7 Mb, state connected
        ip_addr: 2a02:....

So the actual connection method is visible to all participants.

As you say, most USB-NICs are devoid of the usual brace of NIC features (such as RSS, LRO, TSO, TCP/UDP offload etc). The TB3 adapters are much better in this regard with all the usual NIC features included.

️

 

[anthony11]

Ahem, what is false here?

• The Mac Pro does have 2 wired network connections
• All other Macs have a maximum of 1 wired network connection
• Purchasing additional 3rd-party network interfaces is just a way of overcoming the stated limitations

So no, I will not claim that my Mac Studio has 9 wired network interfaces - it has just 1.

️

You answered your own question. And FWIW my Mac Pro has 4 wired connections.

 

[Robbie]

So nothing 'false' then.

️

 

[zombiephysicist]

I just tried SMB again for the zillionth time, and instantly there were issues. And despite "theoretical" speed advantage SMB should enjoy, it's overall slower. So I went back to using AFP which always works great with little to no issues.

 

[Robbie]

@zombiephysicist - That is a shame as AFP is long-since depreciated and is well past having any security updates. I bit the bullet several years ago and worked my SMB config to something that I could use productively. AFP was good in its day and did benefit from the old 'it just works' philosophy.

️

 

[zombiephysicist]

@zombiephysicist - That is a shame as AFP is long-since depreciated and is well past having any security updates. I bit the bullet several years ago and worked my SMB config to something that I could use productively. AFP was good in its day and did benefit from the old 'it just works' philosophy.

️

And yet it still just works. SMB has been a bag full of pain forever. And nothing has changed (as this thread is a living testament to). Maybe someday they will get it right and it might 'just work', but until then, I'll stick with AFP.

 

[HappyDays]

I have been using AFP now for about six weeks rather than battle with SMB's issues and I can report that it has been very stable and I have not had any of the stalls when saving or other symptoms such as spontaneous disconnection of shares that I have previously experienced.

It is however very sluggish to access shares in the Finder using AFP, and I have a different issue which is that if I try to move or delete multiple files in the Finder this often fails.

What I really want is to be able to use SMB and have it work correctly, and I am frustrated that it does not. I am really shocked that neither Synology nor Apple have done the necessary work to make sure that it does function correctly.

I assume the fact that Synology leave the AFP functionality in DSM, and Apple still support it as a client, is a tacit admission that although deprecated there is still a role for it because SMB does not work properly. If SMB was fixed then I guess AFP would in time be not just deprecated but actually removed.

 

[Robbie]

@HappyDays
It's worth noting that for the majority it does all work, including those of us using macOS and iOS with Synology. I have multiple Mac users and multiple Syno NASes and I have no issues. Yes, I have occasionally stumbled into something, or found a tweak that works better for me, or found that a DSM or Apple update disturbs something unexpectedly, or have written guides on here just so that people can get the most of their Apple+Syno experience. I have never had to resort to using AFP.

AFP is there only to support legacy systems and people still use things like Apple Time Capsules that only work with AFP. But it is not supported and nobody is either looking for security issues or addressing the ones already known. If you are running AFP in a DMZ or lab environment then where is the actual risk? Unfortunately NASes are now designed as edge-facing devices or even internet-facing devices. Combine the normal perils and pitfalls of doing that and running depreciated protocols is running-with-scissors. Something that can be forgotten when you have run AFP for years and then do something more internet-facing down the line.

Regarding your AFP issue - moving or deleting multiple files - yes, that is a direct and documented limitation of AFP. It was designed in a different era for a different class of hardware. I mention that here:

Tutorial - Native macOS Finder integration with Synology Universal Search

️

 

[Fortran]

What I really want is to be able to use SMB and have it work correctly, and I am frustrated that it does not. I am really shocked that neither Synology nor Apple have done the necessary work to make sure that it does function correctly.

I assume the fact that Synology leave the AFP functionality in DSM, and Apple still support it as a client, is a tacit admission that although deprecated there is still a role for it because SMB does not work properly. If SMB was fixed then I guess AFP would in time be not just deprecated but actually removed.

As I posted in a previous thread, the issues you are experiencing are by no means universal; there's something specific about your setup (almost certainly on the Mac side) that is causing this. I say this as a user with a completely vanilla Mac SMB config - I don't even have a custom smb.conf on my current M1 Macbook Pro - and have no SMB issues.
The point being, there's hope if you can find whatever config setting is/are causing this.