November 5, 20169 yr Not sure how to report this other than just describe it. Got an email that new version of Plex was available. Logged into UR and went to docker tab. Tried to restart the docker to get the update. No reaction. Chrome spinng showing its waiting for the server to respond. I look over and hard drive lights are lighting up in sequence like the array is spinning up ALL drives. Finally all drives awake and now I regain control over Docker restart command. Updates Plex and able to login there and verify it has new version. My dockers are on a 2 SSD cache drive pool. Never seen it required that array be awake for dockers to be restarted. Diags attached. Happening again right now with latest Plex update. This new behaviour started when I added 2nd Parity drive. How about some help here? If you edit the Plex Docker container and toggle on the Advanced View are there any folder mappings to just '/mnt/user'? Or just post the screenshot of the run command shown here in the Docker FAQ.
November 5, 20169 yr Not sure how to report this other than just describe it. Got an email that new version of Plex was available. Logged into UR and went to docker tab. Tried to restart the docker to get the update. No reaction. Chrome spinng showing its waiting for the server to respond. I look over and hard drive lights are lighting up in sequence like the array is spinning up ALL drives. Finally all drives awake and now I regain control over Docker restart command. Updates Plex and able to login there and verify it has new version. My dockers are on a 2 SSD cache drive pool. Never seen it required that array be awake for dockers to be restarted. Diags attached. Happening again right now with latest Plex update. This new behaviour started when I added 2nd Parity drive. How about some help here? If you edit the Plex Docker container and toggle on the Advanced View are there any folder mappings to just '/mnt/user'? 4 share mapping to /mnt/user/[share_name]/ e.g., /Music <-> /mnt/user/MUSIC/ and one for appdata on cache pool /config <-> /mnt/cache/appdata/plex/
November 5, 20169 yr Not sure how to report this other than just describe it. Got an email that new version of Plex was available. Logged into UR and went to docker tab. Tried to restart the docker to get the update. No reaction. Chrome spinng showing its waiting for the server to respond. I look over and hard drive lights are lighting up in sequence like the array is spinning up ALL drives. Finally all drives awake and now I regain control over Docker restart command. Updates Plex and able to login there and verify it has new version. My dockers are on a 2 SSD cache drive pool. Never seen it required that array be awake for dockers to be restarted. Diags attached. Happening again right now with latest Plex update. This new behaviour started when I added 2nd Parity drive. How about some help here? If you edit the Plex Docker container and toggle on the Advanced View are there any folder mappings to just '/mnt/user'? Or just post the screenshot of the run command shown here in the Docker FAQ. Made two screenshots of a "force update" process, first shows the hang point... the process stopped at this point and each drive in turn was spun up. Looks like the docker update threw an error then deletes the update? Then it finally finished (screen 2). PLex then resumed running as normal. I did get a PlexPy notification that Plex server was down. Then again that it was back up.
November 5, 20169 yr Not sure how to report this other than just describe it. Got an email that new version of Plex was available. Logged into UR and went to docker tab. Tried to restart the docker to get the update. No reaction. Chrome spinng showing its waiting for the server to respond. I look over and hard drive lights are lighting up in sequence like the array is spinning up ALL drives. Finally all drives awake and now I regain control over Docker restart command. Updates Plex and able to login there and verify it has new version. My dockers are on a 2 SSD cache drive pool. Never seen it required that array be awake for dockers to be restarted. Diags attached. Happening again right now with latest Plex update. This new behaviour started when I added 2nd Parity drive. How about some help here? If you edit the Plex Docker container and toggle on the Advanced View are there any folder mappings to just '/mnt/user'? Or just post the screenshot of the run command shown here in the Docker FAQ. Made two screenshots of a "force update" process, first shows the hang point... the process stopped at this point and each drive in turn was spun up. Looks like the docker update threw an error then deletes the update? Then it finally finished (screen 2). PLex then resumed running as normal. I did get a PlexPy notification that Plex server was down. Then again that it was back up. Why are you forcing update on the Plex container? Plex is updated on startup of the container and not on container update (As far as I remember). It looks like Plex and PlexPy shares some container layers or something. Have you tried stopping PlexPy?
November 5, 20169 yr Not sure how to report this other than just describe it. Got an email that new version of Plex was available. Logged into UR and went to docker tab. Tried to restart the docker to get the update. No reaction. Chrome spinng showing its waiting for the server to respond. I look over and hard drive lights are lighting up in sequence like the array is spinning up ALL drives. Finally all drives awake and now I regain control over Docker restart command. Updates Plex and able to login there and verify it has new version. My dockers are on a 2 SSD cache drive pool. Never seen it required that array be awake for dockers to be restarted. Diags attached. Happening again right now with latest Plex update. This new behaviour started when I added 2nd Parity drive. How about some help here? If you edit the Plex Docker container and toggle on the Advanced View are there any folder mappings to just '/mnt/user'? Or just post the screenshot of the run command shown here in the Docker FAQ. Made two screenshots of a "force update" process, first shows the hang point... the process stopped at this point and each drive in turn was spun up. Looks like the docker update threw an error then deletes the update? Then it finally finished (screen 2). PLex then resumed running as normal. I did get a PlexPy notification that Plex server was down. Then again that it was back up. Why are you forcing update on the Plex container? Plex is updated on startup of the container and not on container update (As far as I remember). It looks like Plex and PlexPy shares some container layers or something. Have you tried stopping PlexPy? You are getting distracted. I forced the update to get the screen shots. Yes the removal of the orphan image fails sometimes due to PlexPy. I manually remove it. Neither of those is the issue here. The issue is the array should NOT be spun up to update a docker. ps. I get the same array behavior when I restart the container (to get plex updated version). I can post screens of that if you prefer.
November 5, 20169 yr I see what you mean about updating a container shouldn't need to spin up all your drives. Where's your appdata at? Could it be something to do with appdata in /mnt/user/ You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array. Just thinking out loud here.
November 5, 20169 yr I just tested this on my install, made sure all disks were spun down. Restarted the plex docker with no issues and did not spin up any of my hard drives, then did a force update and again completed with no issues and did not spin up any of my hard drives.
November 5, 20169 yr I see what you mean about updating a container shouldn't need to spin up all your drives. Where's your appdata at? Could it be something to do with appdata in /mnt/user/ You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array. Just thinking out loud here. share setting: appdata Use cache disk: Only docker settings: /config <-> /mnt/cache/appdata/plex/ This is a docker plex install several years old now. The array behavior started when I added Parity 2. Never happened before that. And that is the only material change to my server.
November 5, 20169 yr I see what you mean about updating a container shouldn't need to spin up all your drives. Where's your appdata at? Could it be something to do with appdata in /mnt/user/ You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array. Just thinking out loud here. share setting: appdata Use cache disk: Only docker settings: /config <-> /mnt/cache/appdata/plex/ This is a docker plex install several years old now. The array behavior started when I added Parity 2. Never happened before that. And that is the only material change to my server. Tested all 4 of my dockers regarding restart to update. PlexPy shows the same behaviour (array spins up each disk is examined), while the other 2 (mysql & tt-rss) do not spin up array. PlexPy mappings are all to cache drive, one to its appdata & one to Plex logs. I don't see any errors share settings.
November 5, 20169 yr Where is your docker.img located? Only other thing that I can think of.... on the 2 SSD cache pool where it belongs
November 5, 20169 yr I see what you mean about updating a container shouldn't need to spin up all your drives. Where's your appdata at? Could it be something to do with appdata in /mnt/user/ You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array. Just thinking out loud here. share setting: appdata Use cache disk: Only docker settings: /config <-> /mnt/cache/appdata/plex/ This is a docker plex install several years old now. The array behavior started when I added Parity 2. Never happened before that. And that is the only material change to my server. Try: 1) Stop Docker service 2) Change your appdata user shares' Use cache disk to 'prefer' 3) run the Movers 4) Start Docker service and see if Plex update still spins up all disks
November 5, 20169 yr I see what you mean about updating a container shouldn't need to spin up all your drives. Where's your appdata at? Could it be something to do with appdata in /mnt/user/ You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array. Just thinking out loud here. share setting: appdata Use cache disk: Only docker settings: /config <-> /mnt/cache/appdata/plex/ This is a docker plex install several years old now. The array behavior started when I added Parity 2. Never happened before that. And that is the only material change to my server. Try: 1) Stop Docker service 2) Change your appdata user shares' Use cache disk to 'prefer' 3) run the Movers 4) Start Docker service and see if Plex update still spins up all disks This worked. I did all these (mover didn't have anything to move tho lol). Restarted docker and all except Plex showed updated available. Restarted Plex, no array shenanigans this time. Ran PlexPy update container, again no array spin up. Please explain if you have the time. Curious minds want to know.
November 5, 20169 yr share setting: appdata Use cache disk: Only 2) Change your appdata user shares' Use cache disk to 'prefer' those two lines? Only vs Prefer..
November 5, 20169 yr I just upgraded from 6.2.2 to 6.2.3 through the UnRaid web interface, but on rebooting I now get "kernel panic not syncing" and the server is not booting into UnRaid. Everything was working beautifully before the upgrade. PLEASE HELP!
November 5, 20169 yr share setting: appdata Use cache disk: Only 2) Change your appdata user shares' Use cache disk to 'prefer' those two lines? Only vs Prefer.. That may be the difference, but what is the explanation? I was under the impression that those settings only affected mover, and since nothing needed to be moved, and nothing was moved, I don't get it.
November 5, 20169 yr I just updated and when I try to update MariaDB and Plex, I get this error: Error: layers from manifest don't match image configuration I'm going to stop the dockers and restart them to see what that does.
November 5, 20169 yr This update failed for me coming from 6.1.9. Samba shares became inaccessible from Android, Linux and MacOS devices. Even a loopback Samba attempt from the server itself fails. I tried installing 6.3.0 RC4 and Samba still didn't work. I also tried 6.2.1 unsuccessfully. I couldn't find a download for 6.2 stable. I finally reverted back to 6.1.9 and Samba once again worked. I opened a thread in General Support but nobody helped me. Can anybody help me here? I see that the 6.2 releases included some security fixed for Samba, could that be a clue? Weird that I'm the only person reporting this though... Thanks! Geoff
November 5, 20169 yr I have not been able to update via the GUI moving from 6.2.1 to 6.2.3. See screen capture: What files do I need to copy/overwrite ? to make a clean update from the down load from Lime Tech ? Thanks.
November 5, 20169 yr I have not been able to update via the GUI moving from 6.2.1 to 6.2.3. See screen capture: What files do I need to copy/overwrite ? to make a clean update from the down load from Lime Tech ? Thanks. You can download the release from here: https://lime-technology.com/download/ . Unzip it and then copy the bzimage, bzroot and bzroot-gui files to the /boot/ directory of unRAID. Reboot and you'll be on the latest version. More info here:http://lime-technology.com/forum/index.php?topic=49360.0
November 5, 20169 yr I just updated and when I try to update MariaDB and Plex, I get this error: Error: layers from manifest don't match image configuration I'm going to stop the dockers and restart them to see what that does. There is an entry about that in the docker FAQ.
November 6, 20169 yr Author You guys upgrading from pre-6.2, did you see this in OP? Upgrade Notes If you are upgrading from unRAID Server 6.1.x or earlier, please refer to the Version 6.2.0 release post for important upgrade information. If you follow the link above you will see some info on Docker.
Archived
This topic is now archived and is closed to further replies.