RikStigter

If you expose the web-interface to the internet that would be wise, but do you need to do that? If not (f.i. if you use a VPN to access the web-interface) that is the first thing I'd change. I agree that patching PHP is necessary, but most of us will probably not access UnRaid (i.e. the web-interface) from the internet directly.

All this will remind me I have to document the changes I make... For an old hand like me that should be obvious, but hey... I'm human. 😁 Anyway, everything now seems to work. Now for some fine-tuning.

Thanks a lot Jorge! Have a beer on me! :-)

Hi. I've been updating my harddrives on my Unraid-server (moved Boot from an zfs-array of two SSD's to a single nvme-ssd). I have been messing around with the appdata location. Dockers work (after re-creating the Docker setup) but now I want to install VM's. I've removed the old libvrt iso-image and downloaded a new one, but the service won't start. Included are the diagnostiscs. Before I re-install the whole server (a feasible option since it isn't in production yet) I'd like to understand what is wrong. citadelle-diagnostics-20261008-0715.zip

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!