It’s frustrating that some of you think Plex is playing the blame game. They’re trying to determine what’s wrong and how to fix it. That’s what you do when you’re troubleshooting, you rule things out one at a time. Plex can’t just change something willy-nilly because it might break something else. The fact that this problem is occurring in other apps and not just Plex means the problem is happening and still no one has been able to find out why. How do you even fix something if you don’t know why the problem is occurring? They’re not gods.
MacOS 15.2 beta 1 was released today. I normally have zero interest in beta releases, but considering I only use my Mac mini for Plex, I had nothing to lose installing it… Far too early to tell if it’s a permanent fix, but I purposely closed finder after the drives mounted, rescan, and all is fine. 3 hours later I forced another rescan and all is still good. If you’re in the same boat I am and your Mac’s sole purpose is a plex server, I would recommend trying it.
That’s some good news. I hope someone else can corroborate.
I think you are conflating critique with bashing. I am not bashing.
Honestly, my last post was about a seeming lack of recognition that there are two apps in the same category (media management/server software) that use network shares instead of relying on MacOS to keep the connection/mount.
Both Roon and Emby use SMB network shares.
Here is where Roon keeps their network share mounted:
There is an issue with Plex depending on MacOS and mounted shares via SMB (and AFP), as well as between MacOS and SMB timeouts.
There can be two truths here.
I know that just adding the ability to mount network shares in Plex may have a consequence. My personal opinion, as an individual who works in an adjacent space, is that relying on a point of failure like MacOS and Apple might be something to consider. Maybe they are, and maybe they aren’t. But if you have a best-in-class piece of software like Roon avoiding /Volumes and you have a competitor like Emby avoiding it as well, I would take a look.
You mentioned other apps having this problem as well, but are they using /Volumes for network folders? From my neck of the woods, I can say that Emby and Roon have not had any issues with missing files or drops.
Using /Volumes seems problematic, and I think we are seeing those problems with connecting to mounted folders on a server via /Volumes.
There is plenty written about UNC paths versus mapped drives and the pros and cons.
I tried adding the server address as the library path in Plex, but it did not yield any results. If someone has successfully done this in MacOS, please let me know. I am curious if this fixes anything.
Have you not considered if it was this simple, no one would be still having the issue?
We fully understand what you are trying to share, you’ve explained at least 5 times in this thread. Its not the solution to the issue, as you discovered when adding the library paths produced no results.
I have, and yes, I wish I could add a UNC path like Roon and Emby. I really, genuinely do.
I understand this is a limitation with PMS on MacOs.
Just for clarity here… I also run Emby which has zero issues. But mine is configured to look at the mounted volume in macOS instead of going directly to the network location via SMB. So I’m not sure your theory holds water here. The most likely cause is in the way Plex scans compared to the way Emby and Roon scan.
That being said… I think you are on to something that it would be nice, and probably easier to diagnose when there are issues, for Plex to add an option to go directly to the network share over SMB rather than relying to macOS’s mounted volumes.
@Atomatth @drzoidberg33 @elan… do you think this is a worthwhile idea to put through as a feature request? Here is Emby’s documentation on this feature:
https://emby.media/support/articles/Optional-Network-Paths.html
Sounds like the user would configure both mounted volumes and network share, then the software would decide which is best at any given time. Here is a screenshot of what it looks like in my server.
15.2b1 did not resolve the issue. Finder windows still required.
DSM update 7.2.2 also did not make any changes to this issue.
Confirmed here too, 15.2b1 no effect after this morning, and I also updated to the latest DSM.
Thanks for this response. I feel a little less crazy now.
I think my frustration results from the note about critiquing Plex. Both companies can do whatever they want with their software/hardware. If Apple wanted to ban mounting server drives in applications via MacOS tomorrow, there is very little Plex or any company that relies on that method can do. I’m not saying they would have reason to, but crazier things have happened.
Also, again overnight, the MacOS window for my media reset. The drive is still connected, but I had to go in and reopen the Finder window. Since this is running on a headless Mac mini, it is super frustrating to have to go find my laptop, etc. And Emby and Roon had no issues… womp womp.
It is interesting that you are mounting via /Volumes in Emby and not having an issue, so maybe it is the scanning in Plex/MacOS timeouts or whatever.
Similar to you, this is how I set up my Emby library.
I saw the network path as an option, so I just entered the path to my server folder, which can be found by opening “Get Info,” and copied and pasted it into that line.
I entered my server username and password, and boom, instant addition, and no hiccups since.
I skipped over the optional path since I went direct with the library, but that could be a good option for Plex. If we can’t have UNC, a backup would be nice.
Any word on if the update to v1.41.1.9057 (mac) has resolved any of this?
DSM is also current (as typical for my installation). Mac 15.0.1.
It did not for me.
Server Version#: Version 1.41.1.9057
Player Version#: N/A
Server OS: MacOS
I run Plex Server installed on MacOS. My media files are on a nearby Synology NAS. MacOS connects to the Synology NAS using SMB.
If I reboot everything and re-connect MacOS to the NAS with SMB, then re-scan my Movies directory, about 1/3 of the movies are missing. When I look at my movies in Plex using Folder View, about 1/3 of the folders are simply not there.
When this is happening, the file permissions appear OK. Using terminal on MacOS, the files and folders in question show with these permissions: -rwx------
I can fix the issue by SSH’ing to the NAS, and running chown command to set the owner of all files and movies to the same username used for the SMB connection (even though they already look to be set that way). E.g. ‘sudo chown -R UserName /volume1/movies’. If I subsequently re-scan the library, the missing files are found!
If I re-check permissions on one of the files that was not showing before, it still reads exactly the same from MacOS: -rwx------. I can’t tell why the chown command made a difference.
If I restart everything and re-connect everything, the problem returns. 1/3 of my movie files go missing until I run the magical chown command.
Any ideas what could be the cause of this??
I’m wondering if certain files default to some setting when a new SMB connection is established, somehow related to permissions but not displayed when running ‘ls -al’. Perhaps it’s something that is configured on the SMB server (the NAS) rather than the SMB client (the MacOS that Plex is running on).
Any ideas appreciated!
While I don’t know for sure, I suspect there are issues with Apple’s SMB implementation, file listings, and in-memory caches. So any operation that causes that cache to be refreshed (like crawling through all of the files and checking/setting permissions) might be enough to restore all of the files…until they’re evicted from the cache again. That would mean that anything that just wants top-level file info (like names) would sometimes get the full listing and other times not. Of course, I’m speculating, but it sounds like something in this area.
Now that I think about it, has anyone tried disabling the SMB cache? Disable local SMB directory enumeration caching - Apple Support [I do see a mention of this idea pretty far above, but no confirmation about whether it finally worked…at least that I saw]
Yes, I tried disabling the SMB cache via that config file, rebooted, remounted volumes and no joy. Could still reliably recreate the issue of the failed scans when the Finder windows were closed.
Thanks! I now see that you had replied to your own message a while back…I missed that. I appreciate you responding again.
Mac OS 15.1: just confirming that I can still replicate the issue in Mac OS Sequoia 15.1
Finder windows to mounted shares closed - default scan marks items as missing.
Just popping in to say I’m still here, still monitoring this thread, still nothing to report from our end…
Still hopeful. Thanks everyone for all the back and forth discussions and troubleshooting.
Is it possible for someone at Plex to share the source (or perhaps just details of the source) code that does the scan? Meaning which language, which file API, etc.? I’d be happy to setup a script to run the scan, compare it against the actual file count, and see if I can find more information. I’m a long-time developer, so this would be easy for me to do.



