SMB broken with Monterey

[emura]

Anyone see relief with Ventura? Looking at some of the reddit posts, I'd guess not. May be worse. What a sad state for such basic file sharing functionality. I've switched over most of my primary storage workload to a IODyne Pro Data (DAS with obscene performance), but really want a solid NAS foundation for the bulk of my data (6x8TB DS1621xs+ with good 'ol 10gigE and a 8x8TB DS1821+ for old school 1gigE backups). AFP is my current workaround, but it's deprecated/dead, NFSv3 is a non-starter, and CIFS is so darn high drama all the damn time for decades now. #firstworldproblems

 

[southerndoc]

I've found with Ventura that if my NAS mounts with login (I have it as a login item), I get max throughput of 75 MB/sec. If I dismount and remount it, I get 1000+ MB/sec.

 

[timtrace]

UPDATE: I opened KeyChain Access and removed every entry associated with my array. Rebooted. Was prompted for credentials to connect to the share. SMB works like a champ again.

My Synology array stopped talking SMB with my MacBook after upgrading to Ventura. No prior issues.

I'm hunting for a solution, but will have to go back to AFP or NFS very soon.

DS920+ @ DSM 7.1.1-42962 Update 2
MacBook Pro M1M @ MacOS Ventura 13.0 22A380

 

[emura]

Wanted to report back after moving on to Ventura 13.2.1 - no more hard hangs and lockups with SMB. So I made the move back to SMB from AFP.

That said, I noticed what appeared to be corruption when using the built-in Preview.app on some pretty basic JPGs.

I copied the folder over to a local drive and it was fine via the Preview.app so I looked at the checksums:

[vger:/Volumes/data/corruption] emura% md5 -r * | sort | md5
430dc9f736edea0c6c0bdd433c04c5de

[vger:~/Desktop/corruption] emura% md5 -r * | sort | md5
430dc9f736edea0c6c0bdd433c04c5de


So things are fine at the slightly lower level, not going through Preview.app. I started to think there was a problem with mmap() or similar access via SMB, so I reproduced the Preview.app corruption and saw a ton of these:

10:35:41.505647 getxattr [ 93] /Volumes/data/corruption/FFF_7985_5f90a41a96b6c4c542e1992f81b4ce2b.jpg 0.000618 Preview.620542
10:35:41.542491 getxattr [ 93] /Volumes/data/corruption/FFF_8014_4e995cefb220d9a316d72c486dbcb87b.jpg 0.000499 Preview.620542
10:35:44.100537 getxattr [ 93] /Volumes/data/corruption/ABE_8232_8384c12d276c9156a1077d7d294aad37.jpg 0.000567 Preview.620602
10:35:44.108273 getxattr [ 93] /Volumes/data/corruption/ABE_8287_554421b278c1a7cba401aee06de4f339.jpg 0.000722 Preview.620602


This is "[Errno 93] Protocol not supported" - which correlates perfectly with the files and the symptoms, but not sure about the root cause, esp. since unsupported EA operations are generally not fatal nor important. Also, hitting the error right at open() so that the Preview.app throws the "cannot understand file xxx" is borderline okay, esp. in terms of observability and non-silent errors/corruption, but seeing other files in Preview.app displayed partially fine and then corruption further down the image - that's very, very disturbing.


Unmount and remount of the SMB share "fixed" things, but it's still unsettling to see this sort of behavior.

 

[emura]

I should add that yes, I understand that the EA calls failing shouldn't result in the kind of corruption symptoms I was seeing, but the correlation with the files impacted vs. not lines up perfectly.