I did more testing tonight, and indeed, you only need to include dir_cache_off=yes and mc_on=no to the nsmb.conf file to workaround this issue…at least for those of us who have found some success. Neither one of the settings seems to work by itself.
That said, I have personally found the other settings to improve my SMB experience overall, so they are definitely worth trying.
I am going to package my findings and report them to Apple. The problem is that it requires a non-Apple-hosted SMB share to reproduce the issue, and they might not be as motivated to dig-in. But, we’ll see!
Agreed… if apple-to-apple SMB is not broken, there is almost no shot in Apple doing anything here. We might need Plex devs to chime in here about this to be sure. But given this information, Plex might want to look into how they can adjust their software to eliminate issues like this in the future.
After running Plex directly on my Synology for years, I just moved it over to a brand new M4 Mini & encountered this. Different rescans would result in different quantities found for my largest library (single SMB share), really no predictable reason for it. Strangely about 75% of the time it would settle to 1005 (this number specifically) items found in my largest library.
Also interesting is that I have three other smaller libraries, and none of them seemed to ever be affected. So it certainly seems to affect higher usage SMB shares, mine in question is approaching 4,000 files & 10TB in size.
I quick tested the nsmb.conf recommendations by @Anyware and they did seem to help after some quick tests, so I’m now re-migrating Plex over clean to see if it holds up over time.
Just a quick update, after disabling SMB caching & multichannel (though admittedly I also restricted nsmb.conf to SMB3 at the same time), it’s been 24 hours since rebuilding and everything has been good/stable.
Really weird, but MacOS has something going on here.
My thought process is that the conf file can just stay in place, regardless of if apple fixes the issue or not. It’s not hurting anything, and will give us greater control later, if ever needed.
We are still not able to reproduce the issue of PMS scans causing the mount to timeout/crash/disconnect and therefore marking some significant amount of items to become unavailable. I have seen that the SMB connection just decide to drop I cannot force it to disconnect or reproduce the reported issue using any PMS actions though. Again, without having a way to reproduce this issue it’s difficult to know what PMS is doing that could be causing the issue.
However, it sounds like the work arounds are working well. Big thanks to everyone involved with testing and sharing their findings.
Leaving a Finder window open
Adding /etc/nsmb.conf with:
dir_cache_off=yes
mc_on=no
As for the comments around a way for a direct SMB connection within PMS, this would require a significant amount of resources and not a 1 liner to implement. It’s something that would not likely be implemented quickly enough to be the silver bullet for this issue. Regardless, this feature request is being tracked internally.
The work arounds seem to be holding well for most of us. And, while I cannot speak for everyone, I am happy to continue these work arounds while the Plex team discusses direct SMB connections internally.
I will say this though… I think in the long run it’s in Plex’s best interest to eliminate as much configuration requirements as possible on Apple systems. These last few years of macOS updates have shown, at least from an SMB perspective, that they are OK taking their time fixing and in some cases not fixing at all, these types of issues. Eliminating them from the equation, where you can, could help limit/prevent these types of threads.
For what it’s worth, when I reproduce the SMB issue with my own test app, there is no timeout/crash/disconnect involved. Instead, the directory listing returns fewer entries than actually exist. On the next request, though, it might return the full/correct listing.
Also, this issue won’t reproduce on all SMB share types. For example, I was never able to reproduce it with a Mac hosting the files (meaning, Mac-to-Mac seems to work). The issue happens semi-reliably with Windows 11 and Synology NAS as hosts, though. I tried Ubuntu as a host, but honestly, I forgot how it behaved.
After this issue started, I bought a a m4 mac mini and traded in a m1 mac studio. So I know I have a slower network because the studio had a 10GB card going to the 10GB on the synology, and the new mac mini only has 1GB. SO i know i am only going to get 100 MB/s max most likely, but that should be fine for plex.
But since changing to the mini, and sequoia because it was pre-installed, I also find a lot of users having bad buffering when transcoding. The plex server settings stayed the same as I copied the whole application support folder and plist into preferences. So the settings havent change. So im not clear if its something with these ongoing issues that are causing more issues with throughput to others externally, or if its just that users client being too weak to handle the transcoding?
So i guess im wondering is anyone else having any other issues also besides just the items disappearing on scans that are somehow related to the sequoia update and plex, or is it just me?
I have a 2018 intel nuc8, running win11, that runs like butter, when the m4 mac mini with the same wired connection to the same NAS has had nothing but issues since i got it with Plex. I just cant make sense of it all.
I went from a Mac Mini M1 with 1 GB NIC to Mac Mini M4 with a 10 GB NIC. I still have network issues as everyone has reported. I’ve not had anyone complain when watching videos, although I did see buffering a couple of times locally.
I think the issue stems from a network buffer being too small. It would explain the need to disable directory caching. With caching enabled large folders do not return all the same items. When it only returns a portion of the library folder, the missing items are marked for deletion.
I upgraded to 15.2 and re-enabled directory caching and Multichannel support. Let’s see how long it takes. So far, browsing a folder with over 2000 items shows up almost instantly. It’s much faster.
I noticed there was also a Plex server that included support for not deleting items when the volume is not mounted. That might also help.
I upgraded to macOS 15.2 today and ran my Python SMB thrashing script against a Synology share without the nsmb.conf file. Unfortunately, every run ended in failure. Since this is a statistical bug that is difficult to reproduce, it is possible that the situation has improved…but not enough to prevent the issue entirely.
I cannot force it to disconnect or reproduce the reported issue using any PMS actions though. Again, without having a way to reproduce this issue it’s difficult to know what PMS is doing that could be causing the issue.
