frustratedtech71

Snap.. All sorted.

From their dev page.. explains that this is now to be expected.. Time to update the docker configs. @Tarnous

Just tried updating the docker config to use ghcr.io as opposed to cr.hotio.dev and that appears to have worked on my test

I'm similar in numbers 8 out of 15 all showing all are from cr.hotio.dev/<dockername> Repo does appear to be up so I'm assuming possibly incorrectly that there has been a change made upstream and all dockers will need amending, maybe

Well that is reassurring / concerning. (glad its not just my setup and something I've screwed up accidentally) I'm also showing the same docker status issue. I first thought it was all Hotio dockers but it apears to not be isolated to that repo. Plus checked the repos are up and all have pretty much been updated in the last 96 hours.

Just installed this and its the first one to work without issues.. apart from it being an old version. Thank you @brettm357 Is this still being worked upon or do I need to jump ship before I get started? Any other options available, does anyone know?

@JorgeB Back up and running now thank you, but now another damn drive is failing. Just can't catch a break at the moment.. and still Plex DB is corrupt

@JorgeB I do think the array is now sorted and working. Only thing I've just noticed is that the cache pool has now formatted as btrfs which is slightly annoying. Now just need to resolve the plex database corruption issue. Would appreciate it if you could have a look at the diagnostics and let me know if you can see anything I need to be aware of.. still learning. Thanks again tower-diagnostics-20231203-1449.zip

Thanks yet again @JorgeB every day is becoming a school day for me, with a great tutor. Really appreciate your help so far. Once the original cache data has been copied via mc to disk4\cache\... would I be correct in thinking that the steps are 1. Perform compare within mc to ensure as much is indentical 2. Deselect each of the current SSD from the cache pool 3. Restart the server 4. Configure a new cache pool having cleared the original contents of the existing SSD 5. Start array 6. Configure cache for /appdata /system /iso /domains to prefer cache and manually trigger mover 7. Once confident all data is on cache. (need to find these settings again) setup exclusive access to cache and unconfigure the mover setup? or am I totally over thinking/complicating this?

Finally grabbed some time to look at this. Oddly the plan was to copy the data from cache to disk3 which despite the "main" view indicating plenty of space free I almost immediately received the below error...repeatedly cp: error writing '/cache/cache/appdata/plex/Cache/PhotoTranscoder/55/55524ed89b9c4fbb35e82c1482d70681a003cfbc.jpg': No space left on device So created a new directory on Disk4 and attempted again. This time around a slightly different issue, which does look slightly odd, but might also explain the Plex database corruption and backup failure messages. cp: cannot stat '/mnt/cache/appdata/plex/Cache/PhotoTranscoder/ce/cea4dd8d5e6bf803a56eecfc9b23cf23'$'\230\021\372''Á'$'\210\377\377''.jpg': No such file or directory During which this was occurring I also lost access to the WebGUI, which does appear to be an intermittent fault Logs show Dec 2 11:35:42 Tower rc.diskinfo[20655]: PHP Warning: syntax error, unexpected end of file, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /var/local/emhttp/disks.ini on line 250 Dec 2 11:35:42 Tower rc.diskinfo[20655]: in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 294 Dec 2 11:35:42 Tower rc.diskinfo[20655]: PHP Exception: array_map(): Argument #2 ($array) must be of type array, bool given in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 295 Dec 2 11:38:52 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update Dec 2 11:39:01 Tower crond[1518]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Dec 2 11:39:30 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: uninitialized csrf_token Dec 2 11:39:47 Tower monitor: Stop running nchan processes Which is making life awkward in regards to removing the existing pool and recreating it and of course moving the data back with mover. Any ideas @JorgeB

Good to hear. I'll feedback once I've found the time to suss it all out. Thanks again @JorgeB

Thanks again @JorgeB I'll check the smart reports of the SSD, which to be fair were old surplus but matching so I guess some new WD Red small capacity ones would be a good replacement choice?

Thanks @JorgeB that's certainly reassuring. Can you see any configuration errors in how I'd configured the cache pool in a ZFS mirror/ Just wondering how best to recreate it once the data is relocated? Could I reverse the decision to switch to cache over array, have mover relocate and then delete, recreate the content etc, or would you suggest a totally separate location maybe a unassigned USB drive for instance?

Thanks @Frank1940 I'll take a look but also hang fire for @JorgeB I'm GMT based so JorgeB and I will not be too far apart time wise. The array is currently doing a parity check as it stands (in GUI safemode) having removed the reported failed drive ( which still remains in the chassis just incase ) which as I currently understand it shouldn't be an issue as the data was being emulated from that drive anyway.

So a little further but not sure if its a good thing. In "Safe Mode" I've been able to start the array, however the "Cache Pool" which is a pair of SSD are showing as "Unmountable disks present" which were a zfs pool hosting my appdata, domains, isos and system. So now worried I've lost all my dockers etc that had been working flawlessly. Any ideas would be very gratefully received. Thanks

I've run the command but no idea how to check if thats mounted correctly, so clearly no idea no the backup/recreate neither. With the array stopped I can't see anything as mounted as you'd expect I suppose. Sorry for all the dumb question, I haven't needed to really touch unraid apart from a brief issue when swapping underlying hardware into new chassis, new cpu, GPU and new SAS card at which point the two SSD's were added purely for cache and moved appdata and related elements to the SSD for a performance increase. Diagnostics from the CLI produced are attached now. I'm learning but embarrassingly incapable it seems tower-diagnostics-20231127-1948.zip

I've also attempted to remove the "Disk 6" which was showing as unsupported FS. Which I did with the array stopped changing the disk allocation to "no disk" and attempted to start the array again but no change there either.

I assume the array needs to be running for me to do this, which I'm unable to do right now. I've switched to SafeMode with GUI but don't have the option to download diagnostics but have managed to get syslogs tower-syslog-20231127-1922.zip

Just started in safemode and cannot see a way to gather diagnostics in "Tools" am I missing something? I followed this thread re SafeMode and selected GUI option.

I'll take a look later on and get back to you. I've a few months ago added the pair of ssd as cache zfs pool ( I think) oddly only one appears to have had any data stored on it and up to now performance on plex has considerably quicker. Could I for instance turn docker service off, switch location of the content back to mechanical disk with mover and recreate the cache pool? Make sure it boots and runs correctly then switch back again? I'll try and get diagnostic the last time I tried with the array attempting to start just hung. Is it worth diagnostics without the array operational?

Upgrade As usual followed the flash drive backup via connect. Ran the update assistant which came back clear Performed the update then proceeded to attempt the Plex DB corruption issue Plex DB corruption repair attempt Post Plex docker restart to make sure it was fine Server restart and the array will no longer start. System log shows Nov 23 18:52:38 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update Nov 23 18:55:22 Tower nginx: 2023/11/23 18:55:22 [error] 8765#8765: *6037 upstream timed out (110: Connection timed out) while reading upstream, client: 192.168.0.108, server: , request: "POST /update.htm HTTP/1.1", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "192.168.0.225", referrer: "http://192.168.0.225/Main" I'm unable to get a diagnostics log as I just hangs and the dashboard shows the CPU's slowing one core at a time maxing out. If I restart the server ( Auto Start Disabled ) the server boots, until an attempt to start the array, I've attempted to remove a disabled drive which appeared to be fine but still the array refuses to start. Any ideas would be much appreciated. tower-syslog-20231123-1904.zip DIagnostics.zip

Thanks for the reply. I'll get one of these LSI 6GB 16 PORT PCI-E in it mode and try again. Rudy annoying. Should have checked really.

Does Unraid include any utilities to correct the disk size issue being seen? The disk that was included in the array isn't connected to a different controller to the parity etc so based on that it should be being seen as 4tb. The ssds and 2 further 4tb hdd are connected to the LSI controller. Would you recommend removing the additional disks that had previously not been part of the array and concentrate on somehow sorting the size issue. If so, what would your recommendation be? I'm fine with windows but this not so much.

So the new config was the wrong thing to do.. There is a single disk reporting incorrect at 2.2TB rather than the full 4TB, not two unless I'm missing something The disk was disabled prior to the move to the new hardware. I was just retaining the spindles for continuity. Is there is a way to correct the disk capacity and create a new configuration again? The previous hardware was a 4xHDD server with no room for capacity, Disk 2 was disabled and was allegedly being emulated. My apparently flawed logic suggested the move to a chassis with more disk slots would allow the original disk config. Then slowly introduce the new disk into the array and allow it to rebuild. I assume the xfs_repair in the terminal isn't really going to help resolve anything until the disk capacity correction is done?

Thanks for your message. I did what the previous member had done in regards to new config yes. The disabled disk was in the previous server so for the time being had intended to retain this to keep the configuration as near to original as possible. The motherboard has 6xSata connections and has a mezzanine card with a further 4 sata connectors which is a LSI, can't remember which but will check again. The PDF shows the original disk configuration and correct size. (new hardware is new to me but based on intel S3420GPLX motherboard) I know not great but beggers can't be choosers. I believe the two SSD and and 2 more WD Enterprise 4TB are attached and currently being precleared ( the bottom four on the screen shot )