SMB ISSUES on MacOS

Having issues with 13.0-U6.1 and SMB.

Basically, intermittent and buggy.

Starts out fast and monitoring the NIC in reporting all looks great- near full bandwidth.

But,… the upload then stalls… and, best case, hangs for quite while before resuming… sometimes it just crashes the Mac OS and have to restart finder, then SMB Service onTruenas.

I have 192GB or RAM and 20 cores…reporting shows memory and CPU not really getting hit at all…

The NIC performance correlates with lack of activity on drives in the pool… So, when I see the NIC working at near bandwidth- the drives in the pool are Writing happily… AND, when the NIC traffic drops to Zero… the drives in the pool stop writing… Chicken or Egg, not sure…

Additionally, this happens to any pool - one pool is WD NAS drives other is Seagate EXOS enterprise… So ( thinking it is not drive issue) … 6 drive ZFS2 pool.

Also, this happens on any NIC’s I test… have 10G intel… but also built in 1G ( this is a Dell 720xd btw. ( so not thinking NIC issue)

Also, testing connection to TRUENAS getting full 1G connection.

Client mac’s affected are Monterey, Ventura and Sonoma.

Aso, I have configured shares and smb/mac afp hybrid template…( not using AFP service).

I can see the mountain top!..it is Blazzzing for a minute or two…then stalls…

Attached screen shots are of Upload of 50GB folder… mostly larger mixed files, some photos but mostly video files… not a lot of them, maybe couple hundred.

Please GURU’s of TRUENAS, please share your great wisdom :grinning:

Thanks in advance !!

Aggserv



Are you seeing the same issues with downloading? Does performance stall after a while?

WiteWulf,

Thanks so much for your quick reply : )

Yes, download is having issues too. Starts out fina and then stalls… sometimes

picks up 10 minutes later and finishes… other times, just crashes Finder/OS.

Aggserv

btw, same behavior on PC

Curious, what happens if you test this with a very large file, rather than many small files?

WinnieLinnie,

Thanks so much for your reply : )

I have a 6G install media .ISO and tried testing with that… that file downloads from

the Truenas server fine… but uploading the same file to Truenas failes( "finder can’t complete the opeation… Error code -36 can’t be rEAD or Written)

BTW, same computers, same files have no issue reading and writing to a different
server on 12.0-U7

Sounds like a networking issue of some sort and your client(s) are losing the SMB connection.

Try copying a large file to the NAS and, at the same time, pinging the server. See if packets start dropping or ping time increases.

NB, AFP is deprecated now, not even Apple really supports it anymore.

It looks like you’re using Core, which I don’t know much about, so I’ll tag out here…

Sharing the same resource in two different protocols can be done but should be avoided as much as possible. While TrueNAS is supposed to be keeping track of attempts to modify a file across protocols, collisions are possible (ie someone on AFP and someone else using SMB trying to write to the same file).

I would configure SMB with MacOS character compatibility turned ON (it’s a checkbox in the SMB mount point setup page) so the wider Apple file name character set can be used. Otherwise, you will find your files getting renamed.

Your NIC or switch may be overheating under sustained loads so I’d investigate that angle a bit further.

Another possibility is SMR drives - verify that your pool is not hosted on SMR drives as they are not functionally compatible with ZFS / TrueNAS.

@awalkerix may also have some ideas what might be going wrong between MacOS and SMB on TrueNAS.

Thanks for this idea- really good one, I will start a ping and watch it while things progress and then drop. Very interested to see what happens!

Constantin,

Thanks very much for your reply!

Some additional info:

  1. this issue happens with SMB default configuration setup( I configured it this way initially as it was already working on other Trunas server. Then after experiencing this issue, I read through a lot of posts and was hopeful that recreating the share with the SMB/AFP protocol to allow Mac characters would help( this has been checked in advanced configuration settings) but still issue occurs.

Of note, I have not been using AFP, the service is off… I am curious if it would work without issue, but to your point, it has been depreciated…

Regarding the drive types, I have a Pool of WDigital drives that I have confirmed are CMR and not SMR- they are slower drives, but in other TRUENAS Server work fine. My second pool is faster Seagate and also CMR.

My gut was thinking it was MacOS and SMB and I was missing a configuration on

SMB to make it work----- was so hopeful about adding " strict sync=no" to the smb auxiliary parameters… but alas, though it sped things up, the drops still happened.

Very interesting idea on the NIC’s heating up,…did not think of this, but I do know the 10G nic’s run hot. In relation to that though, this is happening on multiple different NIC’s… I have PCIe NIC’s installed one is 2x1GB and another is 2x10G… both are Intel… this issue happens on both PCI NIC cards as well as the built in 1G ports.

I’d consider putting some fans on the NIC parts to see if that makes a difference. Also, wonder if the switch is having a hard time. Is this SFP+ with a transceiver, if so is it optical or copper?

Ok, some more testing… have started a ping to the Truenas server and monitored it while doing SMB… did notice some " Request timeout for icmp_seq" in the pings… seemed like a lot of them… odd thing is, while pinging, the UPLOAD and DOWNLOAD to the Truenas server worked! no pauses, no crashing of Finder.

However, watching progress on Truenas reporting I noticed something odd.

Both UPload and DOWNload tests were of the same 50GB folder.

Both Up and Down were to the same share ( smb://ip address/Share)

However, while watching the reporting, the UPload showed up on the proper NIC’s reporting RX=931Mbps peak… BUT!!! the download was from a different NIC and IP Address.

I repeated the test and it happened both times… I know the transfers are happening over NIC1 ( SMB://NIC1IPaddress/Share) because other NIC2 is on a different VLAN… So the only way I could map the drive for the transfer tests was to use the NIC1 address. Weird,… have never had any issues like this with Freenas( or Truenas) going back ~10 years.

Odd.

Aggserv

Do you have more than one NIC with IP addresses in the same network? That’s not possible. IP does not work that way.

PMH, thanks for the quick reply. Please elaborate : ) I suffer from both thick skull as well as mush for brains!

For more clarification, I have multiple NIC’S on the Truenas server

PCI NIC1 “ix4” ( 10G Intel, Copper) I have on isolated VLAN only accessible from in office

  • this is all I really need- workstations can get to Truenas Server… but no one else in).

Built in NIC2 “bge2” is on a different VLAN with WAN access for SMTP Notifications, checking for updates, time server etc.

Above is my plan, but for all testing up till now I had only the one ( isolated) VLAN going- all workstations within site of the server ,short run with same gateway, mask, dns set.

But for a little bit I had 2nd NIC with WAN connected so I could check TRUENAS for updates… and I happened to do some tests while connected.

I have attached screenshots to show… but at the time I was doing tests for Upload/Download to the TRUENAS share bge2 happened to be connected( to vlan2 with WAN)… and while looking at reporting I noticed what i described.

I never mapped smb share to ipaddress on bge2.

Sorry if this requires you break my weak networking mind( that resorts to, sigh, subnet calculators… but do as thou must please).

Aggserv