DoS attack against my media server?

Yea... So I'm pretty sure my plex media server was just under some sort of DoS attack.  On my plex media server, the website (127.0.0.1:32400 version of it) was practically unusable.  Thumbnails would take over a minute to load, though if I was patient I'd eventually be able to play some content with plex web. If I tried to go to http://plex.tv/web/app, it'd come up as the server not existing.  After a few minutes my libraries would show up, but clicking them wouldn't do anything but hang. The plex app on my samsung TV was completely useless.  If it manage to load my libraries, it would never show what was inside them.  I waited 10 minutes for one of the loading screens to finish, and it never did.  It was impossible to stream anything.  My roku and android phones were having similar issues.

 

I tried restarting my computer, re-installing PMS (stable version), installing the plex pass version of PMS (seemed even worse), renaming the PMS folder so it'd start from scratch with a new library (the issue seemed to start right after I added a new show, so I originally thought it had something to do with that), and checked my network traffic (nothing abnormal... less than 1% of my bandwidth was in use).

 

Then I tried using my backup NIC.  It changed my internal IP when I plugged it in and I left the port mapped to the old IP so nothing from the outside would get in. Since it has a new IP now, none of my devices inside my home network would be setup to communicate with PMS on the new IP.  Everything was now back to normal!

 

I can't think of anything other than a DoS attack that would have caused this type of issue. I have no idea if it was coming from the devices inside my home network (plex apps) or from the outside.  I didn't think changing my IP would do anything so I didn't check into it before changing it.  If it happens again I'll start monitoring the packets being transfered to/from my computer to see wtf is going on.

 

Any thoughts on this?  Anyone experience something similar?  This confused the crap out of me for hours and I'd like to understand why this happened. If this was a plex app causing the issue, that's one massive bug.  If it was something from the outside... should I be worried? :unsure:

 

 

Edit:  I uploaded some logs in case someone else sees something I missed.  Jun 13, 2014 08:56:16 is when I fixed the issue so look before that point.  Logs before this have rolled over.

Yea... So I'm pretty sure my plex media server was just under some sort of DoS attack. 

....

I can't think of anything other than a DoS attack that would have caused this type of issue. I have no idea if it was coming from the devices inside my home network (plex apps) or from the outside.  I didn't think changing my IP would do anything so I didn't check into it before changing it.  If it happens again I'll start monitoring the packets being transfered to/from my computer to see wtf is going on.

...If it was something from the outside... should I be worried? :unsure:

I think that is jumping to conclusion with no hard evidence. In my view it would be highly unlikely and there would be loads of other possible causes

As always the Plex Media Server.log and any other log files within the Logs folder and Logs\PMS Plugin Logs that were being written to at the time would help give some clues. See Reporting Issues with Plex Media Server for extra debug logging.

I am not going to hypothetise without concrete evidence but i should ask the question - how long was windows running since last reboot? Similarly for Plex Media Server how long since it was restarted?

How could you choose a title as you did for this topic without any evidence of it happening ?? The title implies you had a DoS attack !

I agree. I think you're jumping to conclusions a bit prematurely, migit.

I'm not saying you're wrong, but there are more simple, more likely reasons as to why you might be having problems. Perhaps the NIC just needed to be reinitialized?

What model of NIC is it? Is it wifi? Or a USB dongle? Both?

I think that is jumping to conclusion with no hard evidence. In my view it would be highly unlikely and there would be loads of other possible causes
 
As always the Plex Media Server.log and any other log files within the Logs folder and Logs\PMS Plugin Logs that were being written to at the time would help give some clues. See Reporting Issues with Plex Media Server for extra debug logging.
 
I am not going to hypothetise without concrete evidence but i should ask the question - how long was windows running since last reboot? Similarly for Plex Media Server how long since it was restarted?
 
How could you choose a title as you did for this topic without any evidence of it happening ?? The title implies you had a DoS attack !

 
I put a "?" at the end of the title because I can't prove it.  We had a DDoS attack at work once and this just reminded me of that event way too much.  I probably did jump to conclusions, but it fits in this case (I'm sure other explainations fit too).  I reinstalled everything multiple times so I assumed it wasn't PMS causing the issue.
 
Windows was up for about a week and a half and PMS was up for a few days before I restarted my computer (happened after the restart too)
 
I looked at the PMS logs from when I switched it over to a new PMS folder (The C:\PMS folder).  This removed all my libraries and everything.  I added my TV folder to PMS and the logs show this line about 20 times:
WARN - Error starting transaction (Plugins\PluginDatabaseState.cpp:109) (tries=8): Cannot begin transaction. database is locked

Also 4 ERROR - handle_stream_read error 2 End of file
 
Verbose logging shows a page load took 25 seconds: VERBOSE - Finished writing response for GET /library/sections, 0 bytes in 24757ms
 
In my main server logs(R:\PMS), the db locked error is not present so that shouldn't be the cause of the issue.  The handle_stream_read error occurs 3 times, but it occured twice after I fixed the issue so that isn't it either.
 
I don't see any errors which are in both sets of logs (c:\pms from the fresh library and r:\pms from my normal library) that would explain the slowness.

I uploaded some logs so maybe you'll see something I didn't.  Jun 13, 2014 08:56:16 is when I fixed the issue so look before that point.  Logs before this have rolled over.
 

I agree. I think you're jumping to conclusions a bit prematurely, migit.
 
I'm not saying you're wrong, but there are more simple, more likely reasons as to why you might be having problems. Perhaps the NIC just needed to be reinitialized?
 
What model of NIC is it? Is it wifi? Or a USB dongle? Both?

 
The nic would have been reinitialized when I restarted the computer so that isn't it.
 
Both NICs are on my motherboard.  I was using the realtek nic (it doesn't give its model number in the device manager) since I built the PC with no issues.  I then switched to the Intel 82579V nic after that.

How are you running Plex Media Server on windows (via service, task scheduler or the built in start at login option)?

If you're running it as a scheduled task it could cause apparent slowness/lock ups as all scheduled tasks are run in below normal cpu priority and low memory priority by default (so any other program will have priority over it).

Did you move the localappdata to a network drive / share as opposed to local drive? I have seen lots of issues when users did that. And it also would mean the logs are not trusted as if it cannot access the area for some reason it would not be able to log either

Edit: I am downloading the uploaded log. Slow connection where I am at the moment

PS: From what I have seen from Process Monitor for database accesses and from investigating user issues, I would not support an environment where the local app data is not on a local drive.

How are you running Plex Media Server on windows (via service, task scheduler or the built in start at login option)?

If you're running it as a scheduled task it could cause apparent slowness/lock ups as all scheduled tasks are run in below normal cpu priority and low memory priority by default (so any other program will have priority over it).

It's the standard install on windows 7.  Nothing special.  No services or task scheduler.   The server has 32gb of memory.  This computer cost over $7k so the speed of my equipment shouldn't be the cause of the issue.

Did you move the localappdata to a network drive / share as opposed to local drive? I have seen lots of issues when users did that. And it also would mean the logs are not trusted as if it cannot access the area for some reason it would not be able to log either

Edit: I am downloading the uploaded log. Slow connection where I am at the moment

PS: From what I have seen from Process Monitor for database accesses and from investigating user issues, I would not support an environment where the local app data is not on a local drive.

No network drives. Most drives are attached to my raid controller, which I did speed tests on to confirm that wasn't the issue (was going over 1 gb/s at the start of a read transaction, leveled out around 500mb/s)).  Also it happened on my system drive (an Intel SSD) with read speeds over 500mb/s.

OK so R:\ is a local RAID Drive??

The log file shows transcoding activity and also you probably have indexing enabled on the library. May be it is just the transcoder that is impacting the system performance

Looking before 08:56

There were two network adapters detected -

Jun 13, 2014 08:29:43:081 [6560] DEBUG -  * 12 {8A85A2F9-1884-4E53-B2D6-7BE64F59FC09} (192.168.5.58) (loopback: 0)
Jun 13, 2014 08:29:43:081 [6560] DEBUG -  * 19 {EA2E1887-3702-4A89-9136-43C9E98D72CF} (192.168.56.1) (loopback: 0)
Presume the 192.168.56.1 is to do with using a VM ?

At 08:34 started to stream a video which was being transcoded

Jun 13, 2014 08:34:25:938 [4432] DEBUG - Request: [127.0.0.1:31399] GET /video/:/transcode/universal/start.m3u8?path=http%3A%2F%2F127.0.0.1%3A32400%2Flibrary%2Fmetadata%2F2330&mediaIndex=0&partIndex=0&protocol=hls&offset=0&fastSeek=1&directPlay=0&directStream=1&videoQuality=60&videoResolution=1920x1080&maxVideoBitrate=8000&subtitleSize=100&audioBoost=100&session=l0u1s1bonn&X-Plex-Client-Identifier=b3vfdq0dcln&X-Plex-Product=Plex+Web&X-Plex-Device=Windows&X-Plex-Platform=Firefox&X-Plex-Platform-Version=30.0&X-Plex-Version=2.1.12&X-Plex-Device-Name=Plex+Web+(Firefox) (5 live)
Jun 13, 2014 08:34:25:938 [4612] VERBOSE - [IDLE] * http_download - /web/swf/jwplayer/plex.xml - 1 active item(s)
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * path => http://127.0.0.1:32400/library/metadata/2330
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * mediaIndex => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * partIndex => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * protocol => hls
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * offset => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * fastSeek => 1
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * directPlay => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * directStream => 1
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * videoQuality => 60
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * videoResolution => 1920x1080
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * maxVideoBitrate => 8000
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * subtitleSize => 100
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * audioBoost => 100
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * session => l0u1s1bonn
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Client-Identifier => b3vfdq0dcln
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Product => Plex Web
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Device => Windows
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Platform => Firefox
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Platform-Version => 30.0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Version => 2.1.12
Jun 13, 2014 08:34:25:939 [4432] DEBUG -  * X-Plex-Device-Name => Plex Web (Firefox)
Jun 13, 2014 08:34:25:941 [4432] DEBUG - Using profile Web
...
Jun 13, 2014 08:34:25:945 [4432] DEBUG - [Universal] Using local file path instead of URL: R:\TV\Eureka\Eureka.S03E15.Shower.the.People.mkv
..
Jun 13, 2014 08:34:25:976 [8768] DEBUG - MDE: selected video transcode profile: hls - mpegts/h264/mp3/
...
Jun 13, 2014 08:34:26:026 [4432] INFO - [Transcoder]     Stream #0:0: Video: h264 (High), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
...

There were a lot of trancoder errors to do with accessing the temporary transcode area on the C:\ drive in the temp folder C:\Users\Mike\AppData\Local\Temp\

A variety of errors: Access Denied Error, File not found and Access Violation. 

Some errors indicate that some process had the area open stopping a deletion. Could windows search indexing or anti virus or could be Plex Media Server bug with parallel processes running impacting each other. You may need to run extra diagnostics to determine what it is eg SysInternals Process Monitor. 

Examples:

Jun 13, 2014 08:34:29:893 [2044] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-74903b82-ae33-4703-a922-df31edf711d9\media-00001.ts")
 
Jun 13, 2014 08:35:48:516 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00033.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00033.ts".
 
Jun 13, 2014 08:35:48:520 [4836] ERROR - Caught exception scanning transcoder directory on file 'media-00039.ts': boost::filesystem::status: Access is denied: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00039.ts".
 
Jun 13, 2014 08:35:48:523 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00039.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00039.ts".
 
Jun 13, 2014 08:35:48:524 [8044] ERROR - Caught exception scanning transcoder directory on file 'media-00040.ts': boost::filesystem::file_size: Access is denied: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00040.ts".
 
Jun 13, 2014 08:35:48:526 [1196] ERROR - Couldn't find the file to stream: C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00038.ts
 
Jun 13, 2014 08:35:48:529 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00045.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00045.ts".
 
Jun 13, 2014 08:35:48:723 [8376] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-74903b82-ae33-4703-a922-df31edf711d9
 
Jun 13, 2014 08:43:31:459 [3692] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:625 [3692] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b
 
Jun 13, 2014 08:43:31:625 [3692] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:815 [8196] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b
 
Jun 13, 2014 08:43:31:816 [8196] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:840 [8196] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 

OK so R:\ is a local RAID Drive??

The log file shows transcoding activity and also you probably have indexing enabled on the library. May be it is just the transcoder that is impacting the system performance

Looking before 08:56

There were two network adapters detected -

Jun 13, 2014 08:29:43:081 [6560] DEBUG -  * 12 {8A85A2F9-1884-4E53-B2D6-7BE64F59FC09} (192.168.5.58) (loopback: 0)
Jun 13, 2014 08:29:43:081 [6560] DEBUG -  * 19 {EA2E1887-3702-4A89-9136-43C9E98D72CF} (192.168.56.1) (loopback: 0)
Presume the 192.168.56.1 is to do with using a VM ?

At 08:34 started to stream a video which was being transcoded

Jun 13, 2014 08:34:25:938 [4432] DEBUG - Request: [127.0.0.1:31399] GET /video/:/transcode/universal/start.m3u8?path=http%3A%2F%2F127.0.0.1%3A32400%2Flibrary%2Fmetadata%2F2330&mediaIndex=0&partIndex=0&protocol=hls&offset=0&fastSeek=1&directPlay=0&directStream=1&videoQuality=60&videoResolution=1920x1080&maxVideoBitrate=8000&subtitleSize=100&audioBoost=100&session=l0u1s1bonn&X-Plex-Client-Identifier=b3vfdq0dcln&X-Plex-Product=Plex+Web&X-Plex-Device=Windows&X-Plex-Platform=Firefox&X-Plex-Platform-Version=30.0&X-Plex-Version=2.1.12&X-Plex-Device-Name=Plex+Web+(Firefox) (5 live)
Jun 13, 2014 08:34:25:938 [4612] VERBOSE - [IDLE] * http_download - /web/swf/jwplayer/plex.xml - 1 active item(s)
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * path => http://127.0.0.1:32400/library/metadata/2330
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * mediaIndex => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * partIndex => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * protocol => hls
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * offset => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * fastSeek => 1
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * directPlay => 0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * directStream => 1
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * videoQuality => 60
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * videoResolution => 1920x1080
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * maxVideoBitrate => 8000
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * subtitleSize => 100
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * audioBoost => 100
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * session => l0u1s1bonn
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Client-Identifier => b3vfdq0dcln
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Product => Plex Web
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Device => Windows
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Platform => Firefox
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Platform-Version => 30.0
Jun 13, 2014 08:34:25:938 [4432] DEBUG -  * X-Plex-Version => 2.1.12
Jun 13, 2014 08:34:25:939 [4432] DEBUG -  * X-Plex-Device-Name => Plex Web (Firefox)
Jun 13, 2014 08:34:25:941 [4432] DEBUG - Using profile Web
...
Jun 13, 2014 08:34:25:945 [4432] DEBUG - [Universal] Using local file path instead of URL: R:\TV\Eureka\Eureka.S03E15.Shower.the.People.mkv
..
Jun 13, 2014 08:34:25:976 [8768] DEBUG - MDE: selected video transcode profile: hls - mpegts/h264/mp3/
...
Jun 13, 2014 08:34:26:026 [4432] INFO - [Transcoder]     Stream #0:0: Video: h264 (High), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
...

There were a lot of trancoder errors to do with accessing the temporary transcode area on the C:\ drive in the temp folder C:\Users\Mike\AppData\Local\Temp\

A variety of errors: Access Denied Error, File not found and Access Violation. 

Some errors indicate that some process had the area open stopping a deletion. Could windows search indexing or anti virus or could be Plex Media Server bug with parallel processes running impacting each other. You may need to run extra diagnostics to determine what it is eg SysInternals Process Monitor. 

Examples:

Jun 13, 2014 08:34:29:893 [2044] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-74903b82-ae33-4703-a922-df31edf711d9\media-00001.ts")
 
Jun 13, 2014 08:35:48:516 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00033.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00033.ts".
 
Jun 13, 2014 08:35:48:520 [4836] ERROR - Caught exception scanning transcoder directory on file 'media-00039.ts': boost::filesystem::status: Access is denied: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00039.ts".
 
Jun 13, 2014 08:35:48:523 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00039.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00039.ts".
 
Jun 13, 2014 08:35:48:524 [8044] ERROR - Caught exception scanning transcoder directory on file 'media-00040.ts': boost::filesystem::file_size: Access is denied: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00040.ts".
 
Jun 13, 2014 08:35:48:526 [1196] ERROR - Couldn't find the file to stream: C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00038.ts
 
Jun 13, 2014 08:35:48:529 [9184] ERROR - Caught exception scanning transcoder directory on file 'media-00045.ts': boost::filesystem::file_size: The system cannot find the file specified: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-99157d89-0a5a-476c-84ec-ba36f53797d1\media-00045.ts".
 
Jun 13, 2014 08:35:48:723 [8376] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-l0u1s1bonn-74903b82-ae33-4703-a922-df31edf711d9
 
Jun 13, 2014 08:43:31:459 [3692] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:625 [3692] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b
 
Jun 13, 2014 08:43:31:625 [3692] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:815 [8196] ERROR - Cleaning old transcode directory: C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b
 
Jun 13, 2014 08:43:31:816 [8196] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 
Jun 13, 2014 08:43:31:840 [8196] ERROR - Failed to delete session directory (boost::filesystem::remove: The process cannot access the file because it is being used by another process: "C:\Users\Mike\AppData\Local\Temp\plex-transcode-1GG340053940-8b23a469-b231-4d50-9dd5-9831a12eeb0b\media-00000.ts")
 

I saw these errors as well, but I don't see a scenario where changing my IP would resolve these errors.  I don't believe they had anything to do with the real issue.  The slowness happened when I wasn't transcoding/streaming anything.  Also, the issue was happening over the course of a few hours.  These errors are localized to when I was testing if I could play a video with plexweb locally.  While I was able to do this, it took quite a while to get to the screen where I'd have the option to play it. I do need to go manually clean up plex's temp files every once in a while so this is nothing new.

There are some VMs on this computer (PMS is not in one of them).  That IP (192.168.56.1) appears to be a mirror for my PC.  I'm guessing the virtual box uses that virtual adapter to communicate with the computer it's hosted on.

The problem was general slowness of the website, roku, plex app on my samsung, and my android phones, even when the system appears to be completely idle. The only places I could play a file at was with plexweb locally on the computer PMS is installed on.  It also seemed to get progressively worse over a few hours.  I was originally able to play videos on my samsung TV.  Then it didn't auto start the next episode and when I navigated to play it myself, it did play, but the playback was very laggy.  It'd play a few seconds, then stop (it was not transcoding the video).  After this point the menus on the samsung wouldn't load so I tried the roku and saw similar issues.  Then I tried the website and it was extremely slow when it actually loaded.

What else besides some sort of DoS attack would be resolved after changing my IP?

I saw these errors as well, but I don't see a scenario where changing my IP would resolve these errors.  I don't believe they had anything to do with the real issue.  The slowness happened when I wasn't transcoding/streaming anything.  Also, the issue was happening over the course of a few hours.  These errors are localized to when I was testing if I could play a video with plexweb locally.  While I was able to do this, it took quite a while to get to the screen where I'd have the option to play it. I do need to go manually clean up plex's temp files every once in a while so this is nothing new.

There are some VMs on this computer (PMS is not in one of them).  That IP (192.168.56.1) appears to be a mirror for my PC.  I'm guessing the virtual box uses that virtual adapter to communicate with the computer it's hosted on.

The problem was general slowness of the website, roku, plex app on my samsung, and my android phones, even when the system appears to be completely idle. The only places I could play a file at was with plexweb locally on the computer PMS is installed on.  It also seemed to get progressively worse over a few hours.  I was originally able to play videos on my samsung TV.  Then it didn't auto start the next episode and when I navigated to play it myself, it did play, but the playback was very laggy.  It'd play a few seconds, then stop (it was not transcoding the video).  After this point the menus on the samsung wouldn't load so I tried the roku and saw similar issues.  Then I tried the website and it was extremely slow when it actually loaded.

What else besides some sort of DoS attack would be resolved after changing my IP?

OK. I was going to say a second transcode job started at 08:43 adding to the load on windows. But you say the problem was before doing any transcoding.

Is Media Indexing enabled in the Plex Media Server Settings for Library / Show Advanced. If it is, you could run with it disabled and see if background indexing was a factor

The log starts at 08:29. The transcoding started at 08:34 so only 5 minutes into the start. So probably the relevant log is the one before restarting Plex Media Server at 08:29

I suggest you make sure only 1 network adapter active 

Did you check Task Manager with Show Processes for all users at the time? and from that into Resource Monitor to see what was busy (process view/network view/disk view/memory(

I am concerned about the access denied and the multiple access to. I did come across a case where some anti virus product was having significant impact to performance accessing the plex files

Any other log file was busy at the time? eg we do know that the Neptune DLNA log sometimes has tons of activity and grows to gigabytes in size. Also Logs in the PMS Plugin Logs?

One really needs network capture eg using  Wireshark but you don;t know when it is going to happen. You could also run SysInternals Process Monitor to see what activity is going on. For example recently I discovered Dropbox.exe on my system was accessing some plex files after they were accessed by Plex causing a lockout .

OK. I was going to say a second transcode job started at 08:43 adding to the load on windows. But you say the problem was before doing any transcoding.

Is Media Indexing enabled in the Plex Media Server Settings for Library / Show Advanced. If it is, you could run with it disabled and see if background indexing was a factor

The log starts at 08:29. The transcoding started at 08:34 so only 5 minutes into the start. So probably the relevant log is the one before restarting Plex Media Server at 08:29

I suggest you make sure only 1 network adapter active 

Did you check Task Manager with Show Processes for all users at the time? and from that into Resource Monitor to see what was busy (process view/network view/disk view/memory(

I am concerned about the access denied and the multiple access to. I did come across a case where some anti virus product was having significant impact to performance accessing the plex files

Any other log file was busy at the time? eg we do know that the Neptune DLNA log sometimes has tons of activity and grows to gigabytes in size. Also Logs in the PMS Plugin Logs?

One really needs network capture eg using  Wireshark but you don;t know when it is going to happen. You could also run SysInternals Process Monitor to see what activity is going on. For example recently I discovered Dropbox.exe on my system was accessing some plex files after they were accessed by Plex causing a lockout .

Everything before 8:56:16 was extremely slow, so I don't think PMS was logging whatever was causing the slowness.  From 8:29 till 8:56, nothing really jumps out saying what was happening.  I can't disable the 192.168.56.1 because that would render my VMs useless.  I've had up to 5 running concurrently on this server without any impact to PMS.

Task manager didn't show anything special.  The utilization was below 10%.  There was at least 16gb of memory free before the restart and 28gb free after the restart.  Network usage was below 1% utilized.  The plugin logs didn't show any errors.  The neptune logs (no idea what these are) from my R drive (the fully loaded library), has two entries during the event:

..\Platinum\Source\Core\PltHttpServerTask.cpp(345): [platinum.core.http.servertask] 2014-06-13T07:30:54.081000000-08:00 [PLT_HttpServerSocketTask::SendResponseHeaders] (9060) WARNING: NPT_CHECK failed, result=-20400 (NPT_ERROR_CONNECTION_RESET) [(output_stream.WriteFully(header_stream.GetData(), header_stream.GetDataSize()))]
..\Platinum\Source\Core\PltHttpServerTask.cpp(403): [platinum.core.http.servertask] 2014-06-13T07:30:54.081000000-08:00 [PLT_HttpServerSocketTask::Write] (9060) WARNING: NPT_CHECK failed, result=-20400 (NPT_ERROR_CONNECTION_RESET) [(SendResponseHeaders(response, *output_stream, keep_alive))]

Everything else is after I fixed it.

The C drive's neptune log contains this:

..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (7428) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (5376) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (9084) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (5088) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (8588) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltHttpServerTask.cpp(433): [platinum.core.http.servertask] 2014-06-13T07:29:22.724000000-08:00 [PLT_HttpListenTask::DoRun] (8128) WARNING: PLT_HttpListenTask exiting with -20021 (NPT_ERROR_CANCELLED)
..\Platinum\Source\Core\PltHttpServerTask.cpp(433): [platinum.core.http.servertask] 2014-06-13T07:29:22.824000000-08:00 [PLT_HttpListenTask::DoRun] (5472) WARNING: PLT_HttpListenTask exiting with -20021 (NPT_ERROR_CANCELLED)
..\Platinum\Source\Core\PltHttpServerTask.cpp(176): [platinum.core.http.servertask] 2014-06-13T07:29:22.878000000-08:00 [PLT_HttpServerSocketTask::Read] (5000) WARNING: NPT_CHECK failed, result=-20021 (NPT_ERROR_CANCELLED) [(res)]

I agree that more utilities would be necessary to really determine what happened here.

I just tried reproducing the issue and I think I managed to do it  Switched back to the other IP and manually assigned port 80...  Plexweb just took a minute to load...  I'll make another post soon

Everything before 8:56:16 was extremely slow, so I don't think PMS was logging whatever was causing the slowness.  From 8:29 till 8:56, nothing really jumps out saying what was happening.  I can't disable the 192.168.56.1 because that would render my VMs useless.  I've had up to 5 running concurrently on this server without any impact to PMS.

Task manager didn't show anything special.  The utilization was below 10%.  There was at least 16gb of memory free before the restart and 28gb free after the restart.  Network usage was below 1% utilized.  The plugin logs didn't show any errors.  The neptune logs (no idea what these are) from my R drive (the fully loaded library), has two entries during the event:

..\Platinum\Source\Core\PltHttpServerTask.cpp(345): [platinum.core.http.servertask] 2014-06-13T07:30:54.081000000-08:00 [PLT_HttpServerSocketTask::SendResponseHeaders] (9060) WARNING: NPT_CHECK failed, result=-20400 (NPT_ERROR_CONNECTION_RESET) [(output_stream.WriteFully(header_stream.GetData(), header_stream.GetDataSize()))]
..\Platinum\Source\Core\PltHttpServerTask.cpp(403): [platinum.core.http.servertask] 2014-06-13T07:30:54.081000000-08:00 [PLT_HttpServerSocketTask::Write] (9060) WARNING: NPT_CHECK failed, result=-20400 (NPT_ERROR_CONNECTION_RESET) [(SendResponseHeaders(response, *output_stream, keep_alive))]

Everything else is after I fixed it.

The C drive's neptune log contains this:

..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (7428) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (5376) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (9084) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (5088) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltSsdp.cpp(484): [platinum.core.ssdp] 2014-06-13T07:29:22.673000000-08:00 [PLT_SsdpSearchTask::DoRun] (8588) WARNING: PLT_SsdpSearchTask got an error (-20021) waiting for response
..\Platinum\Source\Core\PltHttpServerTask.cpp(433): [platinum.core.http.servertask] 2014-06-13T07:29:22.724000000-08:00 [PLT_HttpListenTask::DoRun] (8128) WARNING: PLT_HttpListenTask exiting with -20021 (NPT_ERROR_CANCELLED)
..\Platinum\Source\Core\PltHttpServerTask.cpp(433): [platinum.core.http.servertask] 2014-06-13T07:29:22.824000000-08:00 [PLT_HttpListenTask::DoRun] (5472) WARNING: PLT_HttpListenTask exiting with -20021 (NPT_ERROR_CANCELLED)
..\Platinum\Source\Core\PltHttpServerTask.cpp(176): [platinum.core.http.servertask] 2014-06-13T07:29:22.878000000-08:00 [PLT_HttpServerSocketTask::Read] (5000) WARNING: NPT_CHECK failed, result=-20021 (NPT_ERROR_CANCELLED) [(res)]

I agree that more utilities would be necessary to really determine what happened here.

I just tried reproducing the issue and I think I managed to do it  Switched back to the other IP and manually assigned port 80...  Plexweb just took a minute to load...  I'll make another post soon

Isn't use of port 80 asking for trouble ? Why not use some obscure port externally rather than 80? The recommended range to pick a port from is 20000 to 50000

Edit: Run Wireshark and compare what is happening now with the problem on with a wireshark capture when it is ok

Honestly, I don't have a clue how to parse wireshark's logs.  It's logging an insane amount of stuff and I don't know what I should be looking for.  I checked with fiddler and in resource monitor and didn't see an abnormal amount of connections.

I was using Port 80 because I thought the port PMS uses was being limited in my work network.  It was on port 80 for months without any issue.  No idea what changed to cause it to have issues now.

It's back on the old nic under port 32400 and it's running fine.  The issue is specific to port 80.  I'll try it out on port 80 on my other nic tomorrow to see if it happens there too.

I doubt it was a DDoS attack.  If it was that serious, it would have brought your computer to its knees unless you have some really high grade equipment.  Most likely it was just a bot that found port 80 open and started doing a brute force attack to get in.  Now that you've closed port 80, the bot should have moved on.  If you were to switch back, it would probably be fine again until the bot comes around for a another pass.

I use to have this happen when I had an FTP server running on the standard port 21.  Changed it to a random port and no more attempted hacks.

I doubt it was a DDoS attack.  If it was that serious, it would have brought your computer to its knees unless you have some really high grade equipment.  Most likely it was just a bot that found port 80 open and started doing a brute force attack to get in.  Now that you've closed port 80, the bot should have moved on.  If you were to switch back, it would probably be fine again until the bot comes around for a another pass.

I use to have this happen when I had an FTP server running on the standard port 21.  Changed it to a random port and no more attempted hacks.

Still can't use port 80.  Not a huge deal, but it is my preferred port.

Okay. Doesn’t matter what kind of attack it denies Plex media server to playback media on the public port.

Yesterday I changed my port 32400 on the public IP side of things to a random port while PMS runs on 32400 on a port forward. Ooila. Problem solved.

Until the attackers nmap scanned for the new port and then by the next day same thing. Midgit you are absolutely right. PMS needs to control the type of traffic it allows while filtering out attacks.

I have both TCP and UDP is there anyway to remove UDP access without breaking PMS?

UDP is not used by PMS. You only need to forward TCP packets.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.