M1 Mac connected to TrueNAS over SMB keeps crashing - workarounds?

[mbrakes]

After upgrading to a M1 Macbook Pro running MacOS Monterey 12.4 (for video editing etc.) and finally finishing building my TrueNAS server earlier this year, I'm facing some very persistent isues with my M1 Macbook crashing whenever I try to run very large deduplication and backup operations.

I am never able to finish any of these operations because my Mac keeps crashing before the tasks are finished. I've sent a support request to the makers of Chronosync (the sync application I prefer using) and this seems to be a well known issue as they pointed to the following article:

Apple's SMB filesystem client causes system stalls on M1 Macs, leads to kernel panics

The above article recommends using AFP instead of SMB, but when setting up my NAS I followed what seemed to be the general recommendation on these forums; to use SMB. I think I've read somewhere on these forums that accessing shares over AFP and SMB simultaneously is not recommended and a recipe for disaster. So, what then, are my options, short of Apple fixing this issue, which could take months? I need some kind of workaround until Apple are able to sort this out. I'm very much a noob when it comes to TrueNAS and networking in general, so have to rely on advice from my peers here.

All suggestions and advice would be very much appreciated - advance thanks!

 

[elvisimprsntr]

AFP is depreciated and is incompatible with APFS. Any application still using it is obsolete. The link you provide is outdated and likely not relevant anymore. If the third party application still insists on requiring AFP, it's time to find another application.

I have not have any problems with any version of macOS and TrueNAS CORE or SCALE.

1. Don't set up a AFP share or delete any existing shares
2. Set up a multi-protocol SMB share and enable Apple character encoding.

3. Don't enable AFP service.
4. Enable SMB service and enable Apple SMB Extensions

 

[mbrakes]

Thanks @elvisimprsntr, but with the exception of "activate as Home share", my settings match yours.

To my understanding this SMB-issue is just a bug concerning new "silicon" M1 Macs running Monterey, not Macs in general.

 

[anodos]

Thanks @elvisimprsntr, but with the exception of "activate as Home share", my settings match yours.

To my understanding this SMB-issue is just a bug concerning new "silicon" M1 Macs running Monterey, not Macs in general.

I haven't seen this issue with my M1 macs. In general I have seen some cases where failed durable reconnects can cause the MacOS SMB client to hang / "Finder" become unresponsive. Perhaps disable durable handles on the TrueNAS share and see if it resolves the issue.

 

[elvisimprsntr]

To my understanding this SMB-issue is just a bug concerning new "silicon" M1 Macs running Monterey, not Macs in general.

No issues on my '20 M1 MBP

 

[anodos]

The error handling in Finder / MacOS has at times left a lot to be desired. When I was debugging AFP recently I realized for instance that crashing netatalk after finder had mounted an AFP share could cause Finder to hard-lock requiring power-cycle of my MacOS client. I've seen occasionally same thing on SMB-side as well. We actually had to remove the SMB session dead timer from FreeNAS because Finder would hang / crash if its session got scavenged while the Mac was sleeping.

 

[mbrakes]

Thanks a lot @anodos.

Have you found any workarounds which seems to minimize these issues? My M1 Macbook Pro is my "daily driver", but I need external storage for it, and my TrueNAS box is great (super stable, never crashes) except that the crashing issues with M1 Macs is making this combination unusable, as backups and large transfers/sync jobs become virtually impossible.

I file every crash report with Apple, but this has been going on for months now without a fix, and I can't let this go on forever. I need somewhere to store work files after the summer. Without a fix, either the Mac or the TrueNAS box has to go.

 

[mbrakes]

I haven't seen this issue with my M1 macs. In general I have seen some cases where failed durable reconnects can cause the MacOS SMB client to hang / "Finder" become unresponsive. Perhaps disable durable handles on the TrueNAS share and see if it resolves the issue.

Thanks again @anodos, I have disabled durable handles, but still crashing.

 

[mbrakes]

No issues on my '20 M1 MBP

Thanks @elvisimprsntr, I'm happy for you - for what it's worth my Mac is a 16-inch 2021 M1 Max MBP, and it is crashing every single time I try to do any heavy lifting using Arq5, Forklift or Chronosync. It seems like smaller transfers are ok.

 

[mbrakes]

I'm just following up on this in case anybody else are struggling with the same issue.

I found the following post describing issues similar to mine, and applied the suggested workaround, and so far, so good. It is still a bit early to tell for sure, but first file transfers completed OK, so keeping my fingers crossed:

SMB protocol does not work after macOS 11.3.

 

[anodos]

I'm just following up on this in case anybody else are struggling with the same issue.

I found the following post describing issues similar to mine, and applied the suggested workaround, and so far, so good. It is still a bit early to tell for sure, but first file transfers completed OK, so keeping my fingers crossed:

SMB protocol does not work after macOS 11.3.

There was recently a rev of MacOS SMB client where it was performing an invalid compounded SMB operation that would trigger assert (crash) in samba. Latest version of TrueNAS 13 should have workaround applied.

 

[ChrisRJ]

I'm facing some very persistent isues with my M1 Macbook crashing whenever I try to run very large deduplication and backup operations.

Do you mean that you have deduplication enabled? If so, that is most likely the reason for your issues.

 

[mbrakes]

Do you mean that you have deduplication enabled? If so, that is most likely the reason for your issues.

Thanks @ChrisRJ - sorry about the confusing choice of words on my part - no, I didn't mean deduplication the ZFS way, I was running backup and deduplication software from my M1 Mac.

 

[mbrakes]

There was recently a rev of MacOS SMB client where it was performing an invalid compounded SMB operation that would trigger assert (crash) in samba. Latest version of TrueNAS 13 should have workaround applied.

Thanks a lot for the heads up @anodos, I'll look into that as well. But I'm still transferring large folders without crashing here, so it seems like this was a step in the right direction at least. But perhaps we're talking compound issues here, so will check it out. I'm just afraid to break it again if I take further measures now, as per the "if it ain't broken don't fix it" rule

Addendum February 2023: I have since upgraded my Mac to OS X Ventura, and TrueNAS from 12.0-U7 to TrueNAS-13.0-U3.1, and stopped using the Mac apps Forklift and Chronosync as they kept crashing whenever I tried to use them to sync large amounts of files and folders to my servers over SMB. I am having better luck with Get Backup Pro 3, for what it's worth, so I can recommend that for anyone facing the same issues.

Addendum April 2023: I’m still having issues, unfortunately, and keep having to use a windows laptop for heavy lifting of files to and from the TrueNas server. I can mount shares no problem, but as soon as I begin transferring any amount of files and folders, MacOS Finder will crash. I also have two Synology NAS‘es which can connect and transfer any amount of files and folders without any issues, but I have the same Finder crashing issues with an Unraid server. This is driving me nuts, and I’m too busy to spend time troubleshooting….

 

[anodos]

Thanks a lot for the heads up @anodos, I'll look into that as well. But I'm still transferring large folders without crashing here, so it seems like this was a step in the right direction at least. But perhaps we're talking compound issues here, so will check it out. I'm just afraid to break it again if I take further measures now, as per the "if it ain't broken don't fix it" rule

13.0-U3.1 also includes a fix for handling of edge-cases where SMB clients are trying to perform SMB IOCTLs on alternate data streams (which is how MacOS implements xattrs / resource forks over SMB). So it might have been trying to do that as well.