Cessquill

Members
  • Posts

    759
  • Joined

  • Last visited

  • Days Won

    1

Cessquill last won the day on November 21 2018

Cessquill had the most liked content!

About Cessquill

  • Birthday 10/04/1973

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Cessquill's Achievements

Enthusiast

Enthusiast (6/14)

103

Reputation

  1. This thread is for the linuxserverio version of the Plex docker. You've got the plexinc version there. Also, it looks like you're transcoding directly to your array, which I would have thought would be a nightmare.
  2. I'm not sure whether this fix applies to your situation, but I hope your system is more stable now. I've not had another issue since this thread was created, but there may be different issues with different LSI cards - not sure.
  3. Yes. I have the former (a script that puts the Nvidia card into power-save mode). It's duplicated so that it runs on array start, and then hourly. (from a SpaceInvaderOne video)
  4. Yes, but on large libraries you're talking about hours every backup where dockers are off while millions of files are backed up (I estimate that due to backing up my entire Plex folder, my dockers are down for around 10 days every year). Additionally, the amount of storage these files take to back up. Touch wood, I've not had to restore Plex before, but I've refreshed all metadata before and it's not the end of the world.
  5. Thanks for this - had the same problem when upgrading, although I'm not sure whether it didn't coincide with Windows updates, as I reverted back to 6.11.1 from a Flash backup and still couldn't access the shares. Adding "ntlm auth = Yes" fixed it for me.
  6. Fair enough. In my circumstance, the specific configuration of a proxy host in NPM required the site it was pointing at to be running before it would start. If you're sure that's not the case I'll butt out.
  7. Check what other dockers NPM relies on (specifically, more complex sites configured). When I was running a site (the Jitsi docker, I think), if it wasn't running then NPM would never start. If Jitsi was running, NPM would start fine. My guess is that CA is correctly starting NPM, but NPM is shutting itself down, as something it relies on is not present. A few notes: I had this a few years ago, but no longer needed Jitsi (if it was that), so didn't find a solution. I don't know whether CA Backup/Restore adheres to the docker system's ordering and delay options when restarting containers. It's easy to test - shut down dockers one at a time that NPM is linked to and restart NPM. If it doesn't restart with a specific docker stopped, it's likely that this docker is not (fully) running when NPM is restarted following a backup.
  8. It also left my four dockers in question with an unknown update status. That was fixed with a force update on them.
  9. This happened to just earlier too. I got a command failed next to every update and no "done" button on the modal dialog (which leaves a dead page). Four orphaned images to remove, but it looks like the containers updated OK. Was on the way out so didn't get a chance to log or report.
  10. Three posts above yours. With me, it was making sure no other disk activity on my main AppData drive slowed down anything that Plex was doing. I've currently got a lot of read/write on that drive which is slowing my dockers down (trying to track down the culprit).
  11. Unbalance copies then deletes the source files (similar to how Midnight Commander does). If you're moving a lot of data, there may be a cleanup period at the end where the original files are removed.
  12. Absolutely, yes. Thought of that as I was typing - apologies. Fix Common Problems would still warn against a share across multiple pools though, yes? EDIT: I've now gone and set all dockers to point to /mnt/docker/.appdata... Turns out I had already pointed Plex to /mnt/plex/appdata, so I'd obviously started at some point. Also to note, stopped the docker service and set the default docker location to /mnt/docker/appdata
  13. Yep, this is how I have mine set up... An SSD with a cache pool named "Docker" An SSD with a cache pool named "Plex" An "appdata" User share on the Docker pool. All docker appdata is in here except Plex There is also an "appdata" folder on the Plex drive. All Plex appdata is in here "/mnt/user/appdata/" as the Appdata Share (Source) in Backup & Restore sees the folders on both Docker and Plex All docker templates point to /mnt/user/appdata/<docker folder>, but I guess they could point to /mnt/docker/appdata (no idea) Downsides.. Occasionally, a "PlexMediaServer" folder appears on my docker drive - have to move it to the Plex drive (no problems with service, and happens very rarely) Fix Common Problems plugin issues a warning that appdata files/folders exist on the Plex pool. I've just ignored that thinking there's currently no way around it (unless there is and I don't know)
  14. Thanks - two other disks of the same model had spun up, as had the parity. I'll try swapping them around and see what happens.
  15. Hi - On Saturday, I clicked to Spin Up all drives, and when it got to disk 15, both 15 and 16 moved into Unassigned Devices (marked as Array). At this point I rebooted, the attached diagnostics file was automatically created and Unraid rebooted into a parity check. Fortunately the drives were back in the array. I'm trying to work out whether it's a power supply issue (I'm running it pretty full, although it boots fine), an issue with my LSI backplane, a new issue with the latest kernel or something else. I'm aware of the Ironwolf/LSI combo issue that drops drives off when rebooting and have applied recommended settings to all Ironwolfs. Does anybody have any ideas? Unraid is normally rock solid for months, only rebooting for system updates, so I'm a little worried. Any guidance appreciated. unraid1-diagnostics-20220903-1044.zip