Mac clients - SMB cache issues

[HappyDays]

I updated my NAS (a DS418Play, as detailed above) to DSM7.0-41890, hoping that would resolve the issues I have been experiencing with SMB shares from a Macintosh (running Big Sur 11.5). DSM7 has a much more up-to-date version of Samba (4.10.18) than used to be the case with DSM6.2 (4.4.16 at last count).

However if anything the problem is worse. Basically it seems that after a very short while a problem develops linked to the SMB cache. As above, once the problem occurs I can resolve it instantly by either clearing the SMB cache using the button within File Services->SMB->Advanced Settings->General, or restarting Samba from an SSH session.

For an example of what happens once the problem has started, if I simply try to save a file from Preview (specifically a PDF in my case, but I think this happens with other file types as well) to a SMB share on my NAS, Preview stalls with a beachball. Note that this does not happen until the share has been mounted for a while.

I imagine there is something that triggers it but if so I do not know what it is. It could simply be the length of time that the share has been mounted, or the number of files that have been saved to the share.

Another symptom once the problem occurs is that browsing from the Finder takes a long time to list files in folders.

If I either clear the SMB cache or restart Samba then these tasks complete instantly, and accessing files from the SMB share continues to be fast until the next time that the problem develops.

A workaround that I have employed is to create a scheduled job to restart Samba every 30 mins during work hours, and that seems to have resolved the issue for the moment, but I would prefer that Synology address this problem.

The task that needs to be created in the Task Scheduler is (DSM 7+) synosystemctl restart pkg-synosamba-smbd.service, which needs to be run as root.

For DSM 6.2 it is /usr/syno/sbin/synoservice --restart samba, again run as root.

This is very frustrating as it is the only thing that causes any issues with my Macintosh and Synology combination. At least I now know how to resolve it, but it is really annoying that I have to do so. As the fix involves clearing the SMB cache on the Synology box, I can only assume that it is almost certainly not a macOS issue as such.

I would be very grateful to hear whether others have experienced this issue, and whether my workaround resolves it for them.

 

[Rusty]

I can only say that I have no similar problems but I do all my mac <> NAS transfers using Forklift app, not Finder if that makes any difference.

 

[HappyDays]

Interesting, but my major problems are in saving files from within applications. I also have issues in the Finder which seem to be addressed by the same fix, but this is a secondary problem for me.

 

[Rusty]

Interesting, but my major problems are in saving files from within applications. I also have issues in the Finder which seem to be addressed by the same fix, but this is a secondary problem for me.

Mostly I use Pixelmator PRO to R/W from the NAS and I have had no problems at all. Guessing using AFP protocol is not an option?

 

[Robbie]

I use Finder with my NASes every day - one is run 24/7 and 2 are run on a schedule or triggered via WoL.

I do not share any of your issues so perhaps our configurations differ?

 

[HappyDays]

Yes, AFP would be a possibility, but given that Apple have long ago deprecated AFP it seems like a backward step.
[automerge]1633000885[/automerge]

I use Finder with my NASes every day - one is run 24/7 and 2 are run on a schedule or triggered via WoL.

I do not share any of your issues so perhaps our configurations differ?

That's interesting. I have experienced this issue for a good few years through various network implementations and different macOS versions, and consistently with a number of clients on our network here.

I wonder what difference between our configurations could be causing this issue, which is resolved by clearing the SMB cache on the Synology box?

I certainly don't rule out that there is some configuration reason, it's just that the workaround seems to point at a Synology issue rather than anything else, but that diagnosis on my part is certainly not absolute.

 

[Robbie]

I'm off to do other stuff now but when I am free next we could share & compare config settings (if nobody has provided clarity in the interim).

 

[Robbie]

On macOS SMB clients (when connected to a arbitrary share):

rob@Robs-MBP ~ % smbutil statshares -a
==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
iMazing Apple iOS Backups   
                              SERVER_NAME                   Rivendell._smb._tcp.local
                              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.1.1
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------
rob@Robs-MBP ~ %

Slightly expanded if using a macOS M1-based machine:

rob@Robs-MBP ~ % smbutil statshares -a
==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
Hyper Backup Storage 2      
                              SERVER_NAME                   Gimli._smb._tcp.local
                              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.1.1
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              UNIX_SUPPORT                  TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------
rob@Robs-MBP ~ %

On DSM:

More reading on why I set Time Machine Broadcast via SMB even if not used:

Info - How-to fix NAS visibility in macOS Finder sidebar

TL/DR: Clear out recent servers in Finder's 'Connect to Server' dialogue, then: connect to NAS; mount shared folder; disconnect NAS. NAS is now remembered in Finder sidebar. Long version A recent thread on keeping shared folders mounted on macOS got a bit side-tracked with having the NAS...

www.synoforum.com

...and last but not least, my macOS Finder guide here:

Tutorial - Native macOS Finder integration with Synology Universal Search

Native macOS Finder integration with Synology Universal Search Aimed at novice users this is a simple and quick tutorial on how to bring the native capabilities of macOS Finder and full integrate them with Synology’s own Universal Search...

www.synoforum.com

Hopefully we can narrow-down any variations you have to the above.

️

 

[EAZ1964]

I had my share of SMB issues in te past on the Macbook late 2013, most of these have been solved (some came back, and were solved again). All of these were caused by apple, as W10 and linux boxes have been stable over time.

Since 2021 There is my macbook Pro M1 (wireless), and a mac mini M1 (wired), both with Big sur 11.6 at the moment.
SMB has been stable here since 11.13, before that there were numerous SMB issues, similar to the ones you describe.

I can only recommend, if you did not already do this, to do a full reinstall of the mac and see if this resolves the issue. My syno's run almost standard settings, comparable to @Robbie settings. But on V7 and use the VFS module for mac characters. Transport coding is set to defined by the clients.

 

[paradeiser]

Thanks for sharing the settings.

I add another issue, we experience, to the discussion:
When navigating in finder, sporadically it just "jumps" back to the root directory on the SMB share - so you have to navigate all your way again thru the subdirectories. (And hope you don't jump back again, before you arrive.)
DSM 6.2.4 and Big Sur
Happens on multiple machines, so it's not an isolated problem.

Anyone else?

 

[rumorconsumer]

I updated my NAS (a DS418Play, as detailed above) to DSM7.0-41890, hoping that would resolve the issues I have been experiencing with SMB shares from a Macintosh (running Big Sur 11.5). DSM7 has a much more up-to-date version of Samba (4.10.18) than used to be the case with DSM6.2 (4.4.16 at last count).

However if anything the problem is worse. Basically it seems that after a very short while a problem develops linked to the SMB cache. As above, once the problem occurs I can resolve it instantly by either clearing the SMB cache using the button within File Services->SMB->Advanced Settings->General, or restarting Samba from an SSH session.

For an example of what happens once the problem has started, if I simply try to save a file from Preview (specifically a PDF in my case, but I think this happens with other file types as well) to a SMB share on my NAS, Preview stalls with a beachball. Note that this does not happen until the share has been mounted for a while.

I imagine there is something that triggers it but if so I do not know what it is. It could simply be the length of time that the share has been mounted, or the number of files that have been saved to the share.

Another symptom once the problem occurs is that browsing from the Finder takes a long time to list files in folders.

If I either clear the SMB cache or restart Samba then these tasks complete instantly, and accessing files from the SMB share continues to be fast until the next time that the problem develops.

A workaround that I have employed is to create a scheduled job to restart Samba every 30 mins during work hours, and that seems to have resolved the issue for the moment, but I would prefer that Synology address this problem.

The task that needs to be created in the Task Scheduler is (DSM 7+) synosystemctl restart pkg-synosamba-smbd.service, which needs to be run as root.

For DSM 6.2 it is /usr/syno/sbin/synoservice --restart samba, again run as root.

This is very frustrating as it is the only thing that causes any issues with my Macintosh and Synology combination. At least I now know how to resolve it, but it is really annoying that I have to do so. As the fix involves clearing the SMB cache on the Synology box, I can only assume that it is almost certainly not a macOS issue as such.

I would be very grateful to hear whether others have experienced this issue, and whether my workaround resolves it for them.

Having a very similar issue if not the exact same thing. I preview a video files on my NAS which works fine for a while and then slows to a crawl. Resetting my NIC works to fix it for a while then it gets slowwww again. I can make it happen about once every 15 min. Running Monterey on brand new M1 hardware. When it works its snappy AF. When not, molasses.

 

[EAZ1964]

Are you on wifi, or do you use an ethernet Cable with thunderbold/usb3 to ethernet connector?
on internet I’ve read some posts that mention that some thunderbold/ USB3 connectors are causing issues, even sometimes corrupting the data.

on my m1 MBPro i do use an attached dock, and it works ok.

 

[rumorconsumer]

Thanks for the reply. I have used all manner. I have used 2x dongles with Realtek chipsets, the standard one that every dongle has and then the 8156 which uses a different kext. Then I used an intel chipset in a tb3 dock - same issue. Then I used a Sonnet 10gig adapter - same issue. Seems to be occurring above the link layer. Also bare in mind that other connections to other NAS units work fine while one is bugging out so the link itself seems ok.

 

[EAZ1964]

That sounds like solid evidence, good to have ruled that out.

 

[Robbie]

Then I used a Sonnet 10gig adapter - same issue.

I also have a Sonnet 10GbE on an M1, running 24/7 with no issues, via a switch to a Syno NAS - currently a AMD unit but previously an Intel architecture.

Happy to compare your settings to mine.

As a starter for 10, my basic macOS SMB settings but we probably need to go deeper:

Last login: Fri Jun  3 11:14:40 on ttys000
rob@Smaug ~ % smbutil statshares -a

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
Video                         
                              SERVER_NAME                   Rivendell._smb._tcp.local
                              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.1.1
                              SMB_ENCRYPT_ALGORITHMS        AES_128_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_128_GCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_GCM_ENABLED
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              UNIX_SUPPORT                  TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------
rob@Smaug ~ %

️

 

[turing]

I updated my NAS (a DS418Play, as detailed above) to DSM7.0-41890, hoping that would resolve the issues I have been experiencing with SMB shares from a Macintosh (running Big Sur 11.5). DSM7 has a much more up-to-date version of Samba (4.10.18) than used to be the case with DSM6.2 (4.4.16 at last count).

However if anything the problem is worse. Basically it seems that after a very short while a problem develops linked to the SMB cache. As above, once the problem occurs I can resolve it instantly by either clearing the SMB cache using the button within File Services->SMB->Advanced Settings->General, or restarting Samba from an SSH session.

For an example of what happens once the problem has started, if I simply try to save a file from Preview (specifically a PDF in my case, but I think this happens with other file types as well) to a SMB share on my NAS, Preview stalls with a beachball. Note that this does not happen until the share has been mounted for a while.

I imagine there is something that triggers it but if so I do not know what it is. It could simply be the length of time that the share has been mounted, or the number of files that have been saved to the share.

Another symptom once the problem occurs is that browsing from the Finder takes a long time to list files in folders.

If I either clear the SMB cache or restart Samba then these tasks complete instantly, and accessing files from the SMB share continues to be fast until the next time that the problem develops.

A workaround that I have employed is to create a scheduled job to restart Samba every 30 mins during work hours, and that seems to have resolved the issue for the moment, but I would prefer that Synology address this problem.

The task that needs to be created in the Task Scheduler is (DSM 7+) synosystemctl restart pkg-synosamba-smbd.service, which needs to be run as root.

For DSM 6.2 it is /usr/syno/sbin/synoservice --restart samba, again run as root.

This is very frustrating as it is the only thing that causes any issues with my Macintosh and Synology combination. At least I now know how to resolve it, but it is really annoying that I have to do so. As the fix involves clearing the SMB cache on the Synology box, I can only assume that it is almost certainly not a macOS issue as such.

I would be very grateful to hear whether others have experienced this issue, and whether my workaround resolves it for them.

After weeks of fighting with DSM 7.0 using SMB with macOS - shares would just vanish altogether after a while, or drop in the middle of a transfer... or taking long enough listing the files in a directory that applications treated the directory as 'gone' - I contacted Synology support.
They suggested some SMB options to set, which I did.
Nothing improved.
I moved to DSM 7.1, but that didn't make the situation any better and I was beginning to doubt whether it was safe to store files on a NAS that couldn't stay connected for more than a few minutes if the directories involved had more than a few dozen files.
I then disabled SMB and enabled AFP - there are still the occasional disconnections but it is far more stable and able to cope with directories containing significant numbers of files, as well as not dropping the connection while there is activity.

 

[Robbie]

@turing I would not recommend the use of AFP - it is depreciated and not maintained.

Suggest entering this command via macOS Terminal:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Then log out and back in again. This may fix your SMB issues so you can get off AFP.

️

 

[rumorconsumer]

I also have a Sonnet 10GbE on an M1, running 24/7 with no issues, via a switch to a Syno NAS - currently a AMD unit but previously an Intel architecture.

Happy to compare your settings to mine.

As a starter for 10, my basic macOS SMB settings but we probably need to go deeper:

Last login: Fri Jun  3 11:14:40 on ttys000
rob@Smaug ~ % smbutil statshares -a

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
Video                        
                              SERVER_NAME                   Rivendell._smb._tcp.local
                              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.1.1
                              SMB_ENCRYPT_ALGORITHMS        AES_128_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_128_GCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_GCM_ENABLED
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              UNIX_SUPPORT                  TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------
rob@Smaug ~ %

️

Hey Robbie - Thanks for the reply! I verified my output from this command yesterday and it produced the same values. Part of me wonders if its the absolutely vast number of files in this share so Im going to copy my present workspace to another share and see if that resolves things.
[automerge]1654272262[/automerge]

@turing I would not recommend the use of AFP - it is depreciated and not maintained.

Suggest entering this command via macOS Terminal:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Then log out and back in again. This may fix your SMB issues so you can get off AFP.

️

Ive read recently that macOS no longer writes DS_Stores to network volumes. I ran a utility to remove all of mine and tried the command and it did not seem to help.

 

[Robbie]

Ive read recently that macOS no longer writes DS_Stores to network volumes. I ran a utility to remove all of mine and tried the command and it did not seem to help.

I've not seen that from Apple. Perhaps you are referring to the minor change to .DS_Stores from 10.13 onwards? That was only for files sorted alphanumerically and even then Finder will continue to load the rest of the metadata.

 

[rumorconsumer]

I've not seen that from Apple. Perhaps you are referring to the minor change to .DS_Stores from 10.13 onwards? That was only for files sorted alphanumerically and even then Finder will continue to load the rest of the metadata.

Howard Oakley reports it here: https://eclecticlight.co/.../11/27/explainer-ds_store-files/
See his final comment at the bottom of the comments. Dude is an authority.