Mac clients - SMB cache issues

[HappyDays]

Yes, I find this very frustrating. I cannot track down any cause for the problems, but they happen on all clients connected to the NAS and have done for a long period of time, through various versions of DSM and the SMB server package. The problems have become more pronounced in recent times as well. I have tried all sorts of combinations of having an smb.conf file with varying content on the clients, and also not having one. The fact that some of the symptoms do not manifest themselves when using AFP suggests to me that it is likely not to be an issue with the network infrastructure itself.

If I could move back to SMB without the issues I would do it like a shot. I have just never been able to find a reliable solution to the issues that make SMB unusable, particularly with MS Word and the way it deposit folders in the directory you are saving into. I suspect it may be a permissions issue but despite much playing around with this I have never got to the bottom of it. AFP does not, however, exhibit these symptoms.

 

[John82]

Hi HappyDays. Are you using any illegal SMB or international characters or long file names? Even in modern times (Unicode, etc) under certain conditions they may cause issues.

if yes, try to work with shorter Latin only file names and let us know how it’s going…


No such issues here with Intel macOS Ventura and Windows 11 machines.

 

[jann]

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.

Really quick question...and it may not be the issue, but are you mounting using ipv4 or ipv6? if v4, are you doing so by bonjour name (ie: iMac.local.) or by ip address?

I'm on DSM6 and Ventura and turning ipv6 off on my network (i hated doing that!) and mounting smb via ip v4 address and not bonjour name killed all SMB issues.

I know you're on 7 and therefore a much newer SMB, but just offering something that fixed "iffy" smb issues under DSM6 for me.

Jann

 

[HappyDays]

Thanks for the suggestion, but no, I am not (using illegal characters).

-- post merged: 11. Aug 2023 --

Historically I have used both, but right now I have been using the Bonjour name.

I have never used the IPv6 address for a server.

When you say you have "turned off" IPv6 on your network, what are you saying? Maybe what you are saying is that you have set your DHCP server to not assign IPv6 addresses, and also not assigned any IPv6 addresses manually?

I am not sure what difference not using IPv6 could make...

 

[HappyDays]

I am very happy to report that my problems now seem to be resolved, and SMB seems to be operating entirely correctly. I believe that the thing that resolved the problems was weirdly replacing a Netgear gigabit switch on my LAN with a TP-Link model.

I think this was the the thing that fixed the problem although there have been a few other changes at the same time. But since replacing the Netgear switch (a JGS524E) the whole LAN is more stable.

The thing that finally triggered me to change the switch was watching a multi-GB file being transferred to the Synology box and seeing it get only so far before stalling. Power-cycling the Netgear switch caused the transfer to start again and then to complete much more quickly than it was running before the power-cycle.

I have long had a vague suspicion that there is maybe an issue with something like a memory leak in the firmware for Netgear ethernet switches, and this seems consistent with such a problem. I have progressively got rid of them one at a time and this was the last one in a significant location on my network. Eradicating them has definitely improved the stability of the network to a significant degree.

 

[Deleted member 5784]

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.

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.

Thanks for the follow up.

It's hard to understand how your Netgear switch theory fits with your above observations re AFP working whereas SMB doesn't. Network protocols like SMB, NFS and AFP operate at much higher OSI layers (typically levels 5-7, depening on definitions) than switches (usually layer 2 or 3)...iow, that switch isn't aware of whether the packets passing through it are AFP, SMB, NFS or anything else.

Imo it seems more likely that the change of switch coincided with some other config / topology change - eg a recent MacOS update - that is the real reason why your issue has resolved. Regardless, its always good to hear of issues being resolved!

 

[HappyDays]

I agree with what you are saying, bit it is very coincidental that the problems have persisted through multiple iterations of systems, OS, and so on, and despite trying all manner of things with the setup of the clients, but were seemingly fully resolved when the switch was changed. And this is the case for both clients that were accessing the server, and apparently they are not symptoms experienced by others.

But I entirely accept that the switch may not, and should not, have been the cause.

 

[zombiephysicist]

I agree with what you are saying, bit it is very coincidental that the problems have persisted through multiple iterations of systems, OS, and so on, and despite trying all manner of things with the setup of the clients, but were seemingly fully resolved when the switch was changed. And this is the case for both clients that were accessing the server, and apparently they are not symptoms experienced by others.

But I entirely accept that the switch may not, and should not, have been the cause.

I've had weirder things happen. Like cat 5e cable burning out over time. I checked and rechecked everything else. Nothing made sense. Damn cable was just shot. Now I over provision all cables.

 

[John82]

Thanks for the follow up.

It's hard to understand how your Netgear switch theory fits with your above observations re AFP working whereas SMB doesn't. Network protocols like SMB, NFS and AFP operate at much higher OSI layers (typically levels 5-7, depening on definitions) than switches (usually layer 2 or 3)...iow, that switch isn't aware of whether the packets passing through it are AFP, SMB, NFS or anything else.

It’s rare but not impossible for a switch to start behaving weirdly under certain conditions. Not all implementations are the same, they may have bugs…

Of course in this case without any traffic capture analysis it’s just a theory.