RikStigter

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!

LS. About three weeks ago I replaced my flash drive (with the flash tool on a somewhat older Toshiba 2GB USB2 drive that I had lying around) because I was getting errors (on the previously used Sandisk 32GB USB3.0 thumb-drive) while upgrading to 6.11. Now while I'm trying to upgrade to 6.11.1 my 'new' flash drive (The Toshiba/TransMemory drive that I had thoroughly checked before starting to use it) seems to fail again. System is a HP Micrcoserver Gen10. Message while upgrading is: *** bad sha256 on /boot/unRAIDServer/bzroot *** *** The upgrade failed, but no changes were made to your configuration. *** Your USB Flash is likely failing. *** plugin: run failed: /bin/bash Executing hook script: post_plugin_checks I have bought a new drive (a Transcend 4GB USB 2.0 drive) but cannot replace the flash drive before Tue 19 Sep 2023 03:38:24 PM CEST Sincerely yours, Rik Diagnostics attached citadelle-diagnostics-20221008-0828.zip

That is my conclusion as well. Two final questions: Would it be safe to remove the current 'certificate_bundle.pem'? Considering the file's date I'd guess a resounding 'NO' is most likely. The other .pem-file in that directory is old and can probably be removed. I've back upped both, just to be on the sure side. This being a 'hobby'-network I need to make sure I don't have too many complex installation-setups. I'd say that that is probably true for most of us. Now that I have phased out my other servers (Ubuntu LTS and a OMV6-testbed server) I don't have to worry about all the different management-tools anymore. KISS, as it is. 😀 Now I'll be updating my documentation to reflect this wisdom!

Ok, so I think I know why it didn't work. I had made a bit of a hash of my port-forwarding table. Too many entries and no sorting of any kind so barely readable. That's fixed now. One does get a bit complacent using IPv6, I guess. Not a real acceptable reason, but you know... It's a hobby network, mostly. 🤪 Some of my rules were not adjusted correctly to the settings in 'Management Access'. My guess is that I had experimented so much that I forgot some of the things I had tried. <Sigh> I would have had something (tough) to say if that happened during my professional career phase and not just to myself! Now what still does not work is accessing the servers through my own domain with the correct port-adresses, e.g. https://hanebijters2.duckdns.org:xxxxx. That results in a 404 on both servers. Now I could try to find out why, but I have to admit that since it is now working perfectly through https://forums.unraid.net/my-servers/ (and I've bookmarked the new addresses) I'm inclined to think that it isn't worth the trouble anymore. At least not at this time. Other things are waiting for my attention. 😅 Another big thanks to ljm42 for your help. I hope that others may have the same smooth experience with their problems! Rik

Right! A couple of observations: 1) Most definitely not! 1a) Locally that works. When accessed through the My Servers Dashboard ( https://forums.unraid.net/my-servers/ )It rewrites to http://tower.local/login and that is OK. From outside my network it doesn't work: It rewrites to https://www.hash.unraid.net and I reach the base-page of nginx (the 'My Server' page). If I add the newly configured port (https://www.hash.unraid.net:xxxxx it does work. I have changed ports.🙃 For me this is totally workable and secure. Now it gets interesting: 2) Nope, still get 404 with <USE_SSL=yes> 3) DNS rebind is not active on my network as far as I can tell (just checked my router). So I cannot disable it and I still get a 'Server not found'. Now there are a few things that might influence this since I'm running a caching DNS-server (Unbound), I'm running a DShield-honeypot and I'm running IPv6. I'll have to figure out how that might influence the situation, but that requires a lot of hard thought (and lots of paper) and it's still early over here (the Netherlands) as I write this (I'm not putting this to 'it has been a while since I did this kind of stuff on a daily basis', because that would make me feel very old <g>). I'll keep you posted as I go along, but it may take a while... I feel the need for a few espresso's. 🙂 We'll get there. Many thanks and have a pleasant weekend! Rik

Bingo! That works! Cleared the cache for that adress and now it works in 'normal' browser-mode as well. Thank you! Now for the rest of the URL's I have used. I'm including the diagnostics tower-diagnostics-20220520-0632.zip

This is going to take a while so bear with me: I used to have two ways that worked to access my server-GUI for this server and one that didn't work (and that I should have fixed but didn't get around to, I know...): https://hanebijters2.duckdns.org:47438/Dashboard (remote): worked https://192.168.1.223:2443/ (local): worked https://hash.unraid.net (didn't work) If is set <use_ssl no> I get to the login with http://192.168.1.223/login, but I cannot log in! No errors, but no cigar either. (NB! I know username and pwd are correct because I can SSH into the server with those) So the situation now is as follows: https://hanebijters2.duckdns.org:47438/Dashboard gives me a 404 error as does https://192.168.1.223:2443: 404 https://hash.unraid.net gives me a 'can't connect (as before the upgrade from 6.9.2) https://192.168.1.223:1443/ gets me to the nginx server in 'swag', cf. the well known configuration I 'borrowed' from SpaceInvaderOne. Although he was using the Letsencrypt (as swag was formerly known) plugin, the functionality is exactly the same. All GUI's for docker plugins (Syncthing, Nextcloud, Jellyfin, etc.) are perfectly accessible http://192.168.1.223/login brings me to the login screen, but I can't login! No errors, just nothing. Of course it's 5 that is the most annoying. Port-forwarding is as follows: UnRaid_http 80 180 (as suggested by SpaceInvaderOne) UnRaid_https 443 1443 (idem) UnRaid Remote access 47438 2443 (for the unraid.net login) Changing <use_ssl no> to <ussl_ssl yes> (or USE_SSL=yes) and v.v. makes no difference, the results are exactly the same So: I cannot send you my system_diagnostics file, because I still don't have access to the GUI. Is there a command that would create that file? So, basically, I'm stuck right now.