RikStigter

BTW I may not have noticed this because I start the StirlingPDF docker only when I need it. Which isn't very often.

Thanks! Since 7.3.3. is probably not very far away I'll wait for that release and reboot when and if neccesary.

Looking around I've found that this isn't too uncommon. The message was : error: Compressing program wrote following message to stderr when compressing log /var/log/nginx/error.log.1: gzip: stdout: No space left on device error: failed to compress log /var/log/nginx/error.log.1Following the advice from 'Fix Common problems' I'll include the Diagnostics (from before a reboot). I'll reboot after this to clear the problem for now. tower-diagnostics-20261004-0701.zip After a reboot df-h tells me /var/log is now back to 3,2 MB (from 128MB), i.e. 3%.

Arg, I missed the 'Tools > Registration' bit. Sorry about that!

Hi, I'm replacing my Flash-drive (reason: to small for an upgrade to 7.0.1 from 7.0.0). It seems the procedure from https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/ has changed, because folowing this procedure I'm asked to acquire a new license. It tells me there are multiple licenses on the new flash-drive. What is the correct procedure now? Sincerely, Rik Stigter

Interesting to note this happened again this morning on one of my servers after an update of said Plug-in. I've removed the Disk Location Plug-in and the dashboard reappeared. Will monitor this to see whether a newer version will solve this issue.

I've been having the same for a while now on my HP Microserver Gen10. Replacing the USB drive did not solve this. After I run chkdsk on a Windows system on this drive, it updates normally, although it doesn't find any problems with the drive. I'm curious to know if you have the same experience once you done that.

Changing the cable doesn't have any influence, the CRC errors keep mounting. Since this system (a HP Microserver gen10) doesn't have any spare ports left I'll try testing the combo on a different system to see whether I get CRC errors there as well. Done, no errors... Weird. Next I'll do a full 'surface' scan, but meanwhile I'm going to replace the drive cf. the instructions on-line and see what happens next. That will mean reinstalling the single docker (syncthing) I have running on this particular system, but that is easily done. I don't trust anything on this drive, so -recreating some shares on the cache drive etc. is probably wise anyway. It's a simple backup-server so that is no big hassle (I wouldn't recommend doing this on a more complex system). I've managed to save the backup-files to the array on the 'data' share, so this means I'll only have to recreate the appdata share. Done that. Server (so far) runs without errors on the cache drive (with new cable on same SATA-port). Will make new config's for all backups in syncthing and see what happens. Will update if and when new findings. 🙂 After an hour or two no errors on the SSD in use as cache. A surface scan of the old SSD doesn't find any problems. Gremlins?

I have a peculiar problem with my cache drive in one of my servers, a Crucial MX500 1 TB on latest firmware (as recommended): I get CRC-errors on this drive It also shows up as an 'unassigned device' I cannot write to it, 'Fix Common Problems' reports it's read-only I cannot stop the array unless I reboot (and then stop the array before it loads the services) On reboot it starts a parity check This all started after a firmware upgrade that succeeded uneventfully, or so it seemed. Diagnostics attached. I have a spare drive so I would replace it, but I'd rather know what's going on! citadelle-diagnostics-20230627-0920.zip

I can confirm the configuration was still there after upgrading NUT to SimonF's version. Easy upgrade therefore!

Ah, see there is a new version. I thought I was on te latest. II'll update ASAP. Thanx again!

Hello JorgeB Got back this: parent transid verify failed on 531043008512 wanted 616473 found 616472 parent transid verify failed on 531043008512 wanted 616473 found 616472 Couldn't setup log root tree Clearing log on /dev/sdf1, previous log_root 531043008512, level 0 After a reboot everything seems to be OK once again. Dockers are all back. Many thanks! Rik

Some additional info: I had copied some files to the cache and after 3 hours these normally get moved to the array. I'm not sure whether that has had any impact to this problem, but 'gut feeling' says it might. My gut might be wrong. The system is a HP Microserver gen8 (I think you'll be able to see that from the diagnostics file, but nevertheless...) I had already planned some maintenance so I did that this mornbing while I was testing the drive. So it now has a new fan, all dust cleared out (althought t never ran hot, but that is what maintenance is for) and all connectors have been re-inserted. The cache drive is visible to the system, but unformatted. The 'appsdata'-share is totally empty (ths is where the docker files would have resided) My second server (a HP Microsrver gen10) has no problems at all, but 'll check again after copying some fle to it's fle-system

Hi, After an upgrade to 6.12 my system worked fine, but several hours later my cache-disk became unreachable and all dockers failed. The cache-drive sits on a Crucial MX500 2TB, with latest firmware. After extracting it and testing it, it appears that the file-system has gone. I reinserted it in the server. Diagnostics attached. How to proceed from here? Should I erase the disk and rebuild the dockers (It's only three active dockers and they aren't to complex to reinstall)? tower-diagnostics-20230616-0718.zip

Thanks a lot!