Hi, @ChuckPA,
I had a thread a bit ago where we talked about this, refer to https://forums.plex.tv/discussion/322213/is-this-honestly-what-plex-forums-has-come-to-customer-support-beyond-rude#latest
However i am seeing some odd behaviour that really does not seem to indicate that its a cache issue, so i want to follow up.
The kernal log lets me know if the NFS share is unresponsive, yesterday after i manually started a scan to scan a few new movies into the library, i noticed how plex marked a few hundred of my movies as trash, the rest was not marked as trash. I immediately, while it was still scanning, SSHed into the server and browsed to the NFS share, went into a movie folder and listed its contents, i also created a file - It worked fine, so the nfs share was clearly online. The log also did not indicate it was down.
I let the scan finish, and the new movies were added, and a bunch of movies marked as trash. So i scanned it again, the movies that were previously marked as trash was unmarked, but a new set of movies were then marked as trash. I did this over and over again for maybe 4 or 5 scans, and it would constantly rotate and remove trash icon, but add trash icon to a new set of movies.
Until eventually on the last scan, the whole library was fine again.
During all these scans, the NFS library was accessable, there has to be something going on here no?
Yes, something is ‘going on’.
Something with the NFS server is intermittently denying user plex permission to read the share. Remember, just because you can read everything does not automatically mandate user plex has the same access permissions.
@ChuckPA said:
Yes, something is ‘going on’.
Something with the NFS server is intermittently denying user plex permission to read the share. Remember, just because you can read everything does not automatically mandate user plex has the same access permissions.
But why would it only sometimes not have permission to read it? I mean if it has permission now, why wouldn’t it have permission 5 minutes from now?
Thanks for getting back to me!
The File Server is not authenticating user plex consistently
Perform a side by side test.
- While user
plex is being denied access (“Unavailable” trash can is being added)
- Verify your username has full access
Most common solution: Restart the file server
@ChuckPA said:
The File Server is not authenticating user plex consistently
Perform a side by side test.
- While user
plex is being denied access (“Unavailable” trash can is being added)
- Verify your username has full access
Most common solution: Restart the file server
It resolves itself quite fast, so a restart of the file server seems a little over the top.
So if this is actually the case, the auth expires and it attempts to access a file during this time, the nfs server does not accept the new auth request of plex when it attempts to read the file during the period of which the auth has expired?
If your auth is expiring that fast, then you need to address it.
as for “over the top” ? Really? How long does it take to reboot? Even Linux sometimes needs a reboot
@ChuckPA said:
If your auth is expiring that fast, then you need to address it.
as for “over the top” ? Really? How long does it take to reboot? Even Linux sometimes needs a reboot
Well, it’s solved by itself in maybe 30 seconds.
The reason it is annoying is that sometimes I need to run 2 scans when new content I added, the first scan trashes some items, the next scan corrects them.
Those 2 scans take maybe 1 or 2 minutes.
So without a reboot of the nfs service, the issue resolves itself.
The nfs share is ip authenticated, and “everyone” has permission to the folder.
There’s only read access not write. I’m gonna check if I can configure some auth expiration settings on Windows nfs server.
@ChuckPA So i disabled re-auth on the windows NFS server, and all was good for a few days, but the issue still persists.
Today i had the trash icons appear again, first on maybe 20 percent of the library - Then i scanned, then was 75%, then i scanned, then they were all removed.
Meanwhile the NFS was accessable, and kernal logs suggests the drive never dropped connection.
Do you have any other suggestions as to what could be causing this?
I never see this with NFS Linux -> Linux. The only thing I can think of is that Windows is closing the NFS connection and reopening on demand which is consistent with Windows behavior on CIFS shares. iNotify will not tolerate this because the mount point becomes ‘stale’.
@ChuckPA said:
I never see this with NFS Linux → Linux. The only thing I can think of is that Windows is closing the NFS connection and reopening on demand which is consistent with Windows behavior on CIFS shares. iNotify will not tolerate this because the mount point becomes ‘stale’.
I think you are correct with this idea, i have not had this issue since switching to CIFS
