# UnRaid Docker PMS Continuously Executing GET /identity and reading/writing disk array
**URL:** https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737
**Category:** Plex Media Server
**Tags:** server-linux, server-docker, server-unraid
**Created:** [July 31, 2022, 4:35pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737 "2022-07-31T16:35:08Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@shopkins82](https://forums.plex.tv/u/shopkins82)
#### Post date: [July 31, 2022, 4:35pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/1 "2022-07-31T16:35:08Z")
Server Version#: 4.76.1
Player Version#: N/A
I have an UnRAID Docker instance of Plex, with /transcode, /data, and /config on a cache ssd. Every 5 seconds, my Plex server executes the following with a corresponding 60-80kb read and write to my disk array (not the Cache SSD where /data, /transcode, and /config reside):
July 31, 2022 09:59:18.216 [0x14f2bbbe0b38] Debug — Request: [xxx.x.x.x:xxxxx (Loopback)] GET /identity (9 live) Signed-in
July 31, 2022 09:59:18.216 [0x14f2bec2ab38] Debug — Completed: [xxx.x.x.x:xxxxx] 200 GET /identity (9 live) 0ms 398 bytes (pipelined: 1)
I’m not really worried about it keeping the drive spun up (it’s hitting my parity drive and Data 1 drive which would be spun-up anyway, Data 2 and Data 3 spin down fine), but the sound of the repeated reads/writes every 5 seconds is becoming annoying. The 60-80kb being read and written at every 5 second cycle correlates directly with the loopback behavior shown in the Plex Console. Stopping the Plex Docker instance is the only way to stop the behavior.
Thoughts on how to remedy this? And why it’s reading/writing from/to the array and not the cache SSD?
Thanks in advance!
---
### Author:  [@shopkins82](https://forums.plex.tv/u/shopkins82)
#### Post date: [July 31, 2022, 4:40pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/2 "2022-07-31T16:40:18Z")
I also now seem to be getting the following output every 30-40 seconds, but it doesn’t seem to correlate as directly to the disk reads/writes:
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: Entity: line 1:
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: parser
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: error :
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: Start tag expected, ‘\<’ not found
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: status=ok
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - XML: ^
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - Error parsing content.
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - Error parsing XML: Error parsing file.
Jul 31, 2022 12:24:01.988 [0x14a08ab5eb38] ERROR - SSDP: Error parsing device schema for [http://xxx.x.x.x](http://xxx.x.x.x):xxxx
---
### Author:  [@pshanew](https://forums.plex.tv/u/pshanew)
#### Post date: [July 31, 2022, 5:45pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/3 "2022-07-31T17:45:56Z")
Regarding the first issue, it is likely related to the health check being performed by Docker. This thread has some information (there are likely others, but this is the first one I found):
> [@PMS Plex Docker - Constant disk activities](https://forums.plex.tv/t/pms-plex-docker-constant-disk-activities/700600):
>
> Server Version: 4.51.3 Many have already observed this behaviour. The Plex container constantly creates approx 300kb writes to my disks every 1-2s. This wears on the disks and prevent any spindown. Unfortunately all other threads were closed without any resolution. It seems to help to switch to another docker image but there must be a way to get the plex native docker right to avoid that behaviour? Plex surely dont want their SW to be responsible for mutliple HDD/SSD deaths…
* * *
Regarding the second issue, it is the result of Plex Media Server sending SSDP discovery requests on the local network. You have a device (or devices) on your network which is (are) responding, but when queried further replies with invalid information. Plex provides no means by which you can fully disable its usage of SSDP discovery as it is integral to several features. The error messages themselves can be safely ignored, however the errors will always be logged.
You can use iptables or UFW to block outgoing messages to UDP port 1900 (or responses from the specific device) if it causes issues, but be aware it will break certain things (like network tuner automatic discovery).
---
### Author:  [@shopkins82](https://forums.plex.tv/u/shopkins82)
#### Post date: [July 31, 2022, 8:27pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/4 "2022-07-31T20:27:49Z")
I wonder, though, why am I seeing (and hearing) the reads/writes on the disk array when I have Plex Appdata set to go to cache and the /Appdata and /System shares set to Use Cache = Only?
---
### Author:  [@shopkins82](https://forums.plex.tv/u/shopkins82)
#### Post date: [July 31, 2022, 8:36pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/5 "2022-07-31T20:36:27Z")
Figured out why it was writing to the array instead of to the cache… since I’d installed my cache after I set up my Docker containers, docker.img hadn’t moved to the cache. I had to completely disable Docker (not just the containers), run Mover, then re-enable Docker. Now at least I don’t hear the spinning discs reading/writing every 5 seconds (even if it’s probably harder on the SSD in terms of wear-and-tear than it is on the spinning discs).
---
### Author:  [@system](https://forums.plex.tv/u/system)
#### Post date: [October 29, 2022, 8:37pm UTC](https://forums.plex.tv/t/unraid-docker-pms-continuously-executing-get-identity-and-reading-writing-disk-array/802737/6 "2022-10-29T20:37:07Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.