Got to this thread as I’m currently contemplating updating my (still chugging along) 2014 Mac Mini to an M4. I don’t have very much content at all and it’s all stored directly on the Mac for movies and on an attached SSD for TV shows. Is this problem likely to be generated even if using directly attached SSD drives? I’m assuming not but I’ll hold off on the purchase of it will and there’s still an issue to resolve.
Might it be that the chow command is acting like some kind of “pre-processor” that is forcing a refresh of the path/directory listings?
I suspect we are thinking along the same lines. My post about about doing something like an LS[path] for each of the defined Plex paths to “refresh” content or give more time for sleeping drives to awaken and respond.
BINGEAUX!
the chow and LS commands would do both of those. Adding a couple of lines of code to do an inert command to pre-process the path before handing off the Plex call to the directory listing. Something like LS would take no real action but force a refresh.
Ditto here
You’ll be fine. We have some work arounds that are chugging along well for now and Plex is spending TV money for new customers so they aren’t ignore this.
This issue is specific to connecting to storage drives over the network using SMB protocol. The setup you described wouldn’t be affected.
Version 1.41.2.9134
did not resolve the issue.
still needing to leave Finder windows/tabs open to each large media folder. (smaller folders are still fine)
Have we proven that it’s only when library folders contain more than 1,000 entries / directories within?
My movie library has about 1,500 movies. I notice when the issue occurs, it finds about 998 of them. Is it identical for others?
I’m wondering if MacOS enumeration caching limits itself to 1,000 entries until manually browsed or some other change causes it to refresh.
I’ll also try disabling the SMB enumeration caching when I can to see if I get different results from the other user that tried it. It seems like a theory that fits perfectly.
If it’s the case, maybe a work-around is for the Plex software to do some small action that triggers the refresh. It’s not an ideal solution but may be the quickest solution.
Perhaps there’s a magic #, but “large” library as being discussed here, is relative. I have a library with around 7K highly compressed movies (12TB), and it gets chopped down to around 2K. I have another library with only 4K Remux stuff (31TB) with 933 movies, and it is not affected. But…
My main music library has around 3K files (1TB), and is unaffected. Another library with 5K files is unaffected. But another compressed library with 76K files (1.1TB) is affected.
So if you’re having problems with 1500 movies, but I don’t have a problem with 5K music files, it must be some combination of size & file count screwing things up.
Although anecdotal, I decided to switch to NFSv4 a few days ago due to ongoing issues with SMB, which could be related to macOS Sequoia betas, Synology DSM, or Plex Media Server. Since making the change, I haven’t experienced any issues, and I’ve noticed a welcome boost in network performance.
I’m currently on macOS Sequoia 15.2 Beta (24C5057p) with Plex Media Server Version 1.41.1.9057, streaming from a library on a Synology NAS running DSM 7.2.2-72806.
Setting up NFS was straightforward, and I configured it to mount the network share automatically via a LaunchDaemon.
& @onethumb Thanks both. I assumed that would be the case but I’ve been caught out before by my assumptions LOL, so prefer to be certain.
I have done the same since seeing this, and have no issues since. Everything is back to normal. Have been able to re-enable all the normal settings for scanning. It seems to be snappier as well, faster performance.
What is the downside of using NFS vs SMB?
Are there any?
Both ChatGPT and Perplexity gave similar responses. Since I don’t have any Windows machines at home, I’ll stick with NFS for now.
When to Use NFS or SMB
• Use NFS if you’re primarily working in Unix/Linux and macOS environments and need faster performance with less overhead, especially for large files or high-throughput operations.
• Use SMB if you have a mixed OS environment, need better security features, or are working with applications requiring file-locking. It’s particularly advantageous if you have Windows systems involved.
Has anyone else tried NFS?
All good on movie scans?
Updating the thread to say that I enabled the NFS protocol on my Synology NAS and then forced the mount on my MacOS Plex server to use NFS and everything seems to be working quite well! In fact, I am also seeing a noticeable increase in network file transfer speeds and my first library scan actually picked up 4 movie titles that were missing from my library! (seems that for whatever reason, the SMB share just wasn’t detecting these 4 movies despite the folders / files always being there and visible in SMB - I just never noticed that they were missing from my Plex library).
I think I’m going to move forward with this configuration now. Windows machines on my network will continue to use SMB while my Mac machines will use NFS going forward.
Thanks @Ph03n1ks and everyone else on this thread!
Thanks for the update, @jasonwalker and @aibradford ! It’s good to see the list of “anecdotal cases” steadily growing.
After diving deeper into the differences between NFS and SMB, here’s what I found:
NFS (Network File System) stands out as a stateless protocol. Each client request is treated independently, so NFS doesn’t maintain an ongoing session with the server. This makes it more resilient to network hiccups, as it can resume without needing to re-establish a session. If there’s a brief network issue, NFS usually bounces back smoothly.
In contrast, SMB (Server Message Block) is stateful, maintaining an active session that includes metadata and permissions between client and server. This setup can enhance access speed by caching information, but if the connection drops, SMB may require a full reconnection or re-authentication, often causing a noticeable delay, and perhaps other issues as well.
Hello everyone,
Just wanted to say that I have been suffering this issue since September and after finding this thread I have activated NFS and all seems good now.
Here is an AI generated manual on how to do it:
To configure your Mac running macOS Sonoma 15.1 to automatically mount a read-write NFS share from your Synology NAS at startup, follow these steps:
Step 1: Enable NFS Service on Synology NAS
-
Log in to your Synology NAS.
-
Open Control Panel.
-
Navigate to File Services.
-
Under the NFS Service tab, check Enable NFS.
-
Click Apply to save the changes.
Step 2: Set NFS Permissions for the Shared Folder
-
In Control Panel, go to Shared Folder.
-
Select the folder you wish to share via NFS and click Edit.
-
Navigate to the NFS Permissions tab.
-
Click Create and configure the following settings:
• Hostname or IP: Enter the IP address of your Mac or a wildcard (*) to allow all.
• Privilege: Set to Read/Write.
• Squash: Choose Map all users to admin for simplicity.
• Security: Select SYS.
- Click OK to apply the permissions.
Step 3: Configure autofs on macOS
-
Open the Terminal application on your Mac.
-
Edit the auto_master file:
sudo nano /etc/auto_master
- Add the following line at the end of the file:
/- auto_nfs -nobrowse,nosuid
This line directs the system to refer to the /etc/auto_nfs file for direct mappings.
- Save and exit the editor (in nano, press Control + O to save, then Control + X to exit).
Step 4: Create the auto_nfs Map
- In Terminal, create and edit the /etc/auto_nfs file:
sudo nano /etc/auto_nfs
- Add a line specifying the mount point and NFS server details:
/System/Volumes/Data/Users/yourusername/mounts/nfs_share -fstype=nfs,rw,nolockd,resvport,hard,bg,intr,tcp,nfc,rsize=8192,wsize=8192 nfs://synology_nas_ip:/volume1/your_shared_folder
Replace:
• /System/Volumes/Data/Users/yourusername/mounts/nfs_share with your desired local mount point.
• synology_nas_ip with the IP address of your Synology NAS.
• /volume1/your_shared_folder with the path to your shared folder on the NAS.
Step 5: Create the Local Mount Point Directory
- Ensure the local mount point directory exists:
sudo mkdir -p /System/Volumes/Data/Users/yourusername/mounts/nfs_share
- Adjust the ownership and permissions:
sudo chown yourusername:staff /System/Volumes/Data/Users/yourusername/mounts/nfs_share
sudo chmod 755 /System/Volumes/Data/Users/yourusername/mounts/nfs_share
Replace yourusername with your actual macOS username.
Step 6: Apply the Configuration
- Reload the autofs configuration to apply the changes:
sudo automount -vc
This command will unmount and remount all autofs-managed mounts, applying your new configuration.
Additional Considerations:
• macOS Catalina and Later: Due to the system volume being read-only, mount points should be created under /System/Volumes/Data. (Tisgoud)
• Security & Permissions: Ensure that the NFS server allows your Mac to connect and that the appropriate permissions are set for read-write access.
• Testing: After completing the setup, navigate to the mount point in Finder or Terminal to verify that the NFS share mounts correctly and is accessible.
By following these steps, your Mac will automatically mount the specified NFS share from your Synology NAS in read-write mode whenever you access the designated mount point.
If you find issues when trying to edit /etc/auto_master and trying to save it says [ Cannot open file for writing: Operation not permitted ] then do this:
The “Operation not permitted” error when attempting to edit system files like /etc/auto_master on macOS Sonoma 15.1 is due to enhanced security measures, specifically System Integrity Protection (SIP). SIP restricts modifications to certain system files and directories to protect the operating system.
To edit /etc/auto_master**, follow these steps:**
- Disable System Integrity Protection (SIP):
Disabling SIP allows modifications to protected system files. Ensure you re-enable SIP after making the necessary changes to maintain system security.
• Restart your Mac in Recovery Mode:
-
Click the Apple menu and select Restart.
-
Immediately press and hold Command (⌘) + R until the Apple logo appears, initiating Recovery Mode.
• Open Terminal in Recovery Mode:
-
In the macOS Utilities window, select Utilities from the menu bar.
-
Choose Terminal.
• Disable SIP:
- In the Terminal window, type:
csrutil disable
-
Press Enter.
-
After the process completes, restart your Mac by selecting Apple menu > Restart.
-
Edit the /etc/auto_master File:
• Open Terminal:
- Once your Mac restarts, open the Terminal application.
• Edit the File:
- Type:
sudo nano /etc/auto_master
-
Press Enter.
-
Enter your administrator password when prompted.
-
Make the necessary changes to the file.
-
Save the changes by pressing Control (⌃) + O, then press Enter.
-
Exit the editor by pressing Control (⌃) + X.
-
Re-enable System Integrity Protection (SIP):
It’s crucial to re-enable SIP to maintain your Mac’s security.
• Restart in Recovery Mode:
-
Click the Apple menu and select Restart.
-
Immediately press and hold Command (⌘) + R until the Apple logo appears.
• Open Terminal in Recovery Mode:
-
In the macOS Utilities window, select Utilities from the menu bar.
-
Choose Terminal.
• Enable SIP:
- In the Terminal window, type:
csrutil enable
-
Press Enter.
-
After the process completes, restart your Mac by selecting Apple menu > Restart.
By following these steps, you can modify the /etc/auto_master file to configure your NFS share and ensure your system remains protected by re-enabling SIP afterward.
Note: Disabling SIP reduces your Mac’s security. Only disable it temporarily to make necessary changes, and always re-enable it immediately after.
I think this issue reflects a larger problem and highlights a much-needed feature to be added.
When you add a library, Plex should create a file in the root of that directory. When that file is missing, Plex would assume that the path to the library is currently unavailable. So this would be different than Plex assuming the media files have been deleted. The third-party script autoscan has this thing called anchor files. It’s just an empty file, but when it’s not present, it prevents autoscan from performing tasks on that path.
We’ve all heard horror stories of their entire library being wiped out because a drive didn’t properly mount. This would prevent that.
Tagging @Atomatth for consideration ![]()
@ChristianKent Plex does have logic built into the code for detecting missing drives. Its not perfect, and in this case due to SMB delays plex detects some files but not everything. How is an app supposed to tell the difference between you removing files, and only a partial successful scan?
My suggestion isn’t a fix for the current problem in this thread (since we don’t even exactly know what’s wrong), but it’s somewhat related to mounts disappearing so I thought I’d mention it.