I have been using my backup script for backing up Plex metadata for several months and a couple of weeks ago I started having the following problem: after the script restarts the PMS process (the script stops PMS, performs backup, and starts PMS), the PMS instance seems to lose ability to see the NAS share hosting media files.
I use UNC paths for media library mappings, so it is not an issue with the mapped drive. The backup script runs under the same account as PMS. PMS itself starts fine and I can get to the UI, but as soon as I try to play a video, I get the âPlease check that the file exists and the necessary drive is mountedâ error. After I restart PMS manually it starts working again.
I stop PMS via the PowerShellâs taskkill /f /im $plexServerExeFileName /t command, and start it using Start-Process $plexServerExePath -LoadUserProfile.
I added code to list media directory files before starting PMS, but it is not helping.
One caveat: if I launch the backup script manually, there is no problem. It only happens when the script runs as a scheduled task (the scheduled task runs with Administratorâs privileges under the same account as PMS).
Any ideas? Thanks.
P.S. Just checked the log and it has the following entry:
Jun 20, 2019 14:05:32.249 [4344] ERROR - Couldnât check for the existence of file â\\MYNAS\Movies\Movie XYZ\Movie XYZ.mp4â: boost::filesystem::status: The user name or password is incorrect: â\MYNAS\Movies\Movie XYZ\Movie XYZ.mp4â
Jun 20, 2019 14:05:32.460 [4344] ERROR - Error opening file ââ\\MYNAS\Movies\Movie XYZ\Movie XYZ.mp4ââ - Invalid argument (22)
I checked Task Manager and the PMS process is running under the proper account.
Thank you @trumpy81, but I do not see how or why this would make a difference. I actually had someone using my script who had the exact same issue and he had the NAS share mapped to a letter drive. I recommended him switching to the UNC paths and it seemed to have solved the issue for him. So it does not seem to be cased by the UNC vs. the drive letter share mapping.
The basic question is: why would a PMS instance launched from a scheduled task not have access to a NAS share while a PMS instance launched manually under the same account would be able to access the very same share just fine? Is there some trick in how PMS gets started (or should be stopped)?
I am no expert, but as I understand it, as soon as you execute a script or app with admin privileges, you are actually running as the user âAdministratorâ. And no longer as your regular user name.
Which then negates your access to the NAS, since it has only access permissions for your regular user account.
The solution would be to:
create a user account with administrative privileges
run the script under this special user account
create access permissions for this user on the NAS (you need to use the same user name and password on the NAS as you are using on the Windows machine. Never rely on Windows to store the access credentials for network shares â it doesnât work reliably.)
I do not think thatâs how Windows security works. If you run as an Administrator, you still run as you. The only difference is that you run with elevated privileges that allow you to do special things, like starting/stopping services, writing to system folders, etc. In fact. I am doing exactly what you are recommending: the windows account is an administrator and it is in sync with the NAS account. And the PMS instance is launched as this account, so itâs all as it is supposed to be. And it worked fine for a few months. Iâm not sure if something got corrupted or some update broke something. I saw a few posts with people complaining about simar issues that are not related to Plex, so this is most likely a Windows issue.
I do run Plex as a regular user. I run the script as the same user too but with the âHighest privilegesâ checked (which is the same as running âAs Administratorâ, I assume).
Anyway, I did a couple of things (unchecked the energy setting allowing computer to turn network adapter off to save power, updated the NAS OS version), and one of them must have fixed the problem since my last backup worked as expected. I will keep an eye on it and post an update in case someone has a similar issue. Thanks for all of your suggestions.
