sonofdbn

The drive is still in the array, so I can't see what the top looks like. But here's where I saw the model number in some HGST document. It's a Deskstar NAS and there's no mention of helium anywhere. Casual Googling shows that most (all?) HGST helium drive model numbers start with HUH and are Ultrastars. Or perhaps I'm so far behind the tech that most modern drives are helium drives so they don't bother mentioning it?

I have an HGST Deskstar NAS drive in my array. Model is HDN728080ALE604, and from what I can find, it's not a helium drive (and I don't recall ever buying a helium drive). But I'm getting this in my notification email from the server: Subject: Warning [TOWER] - helium level (failing now) is 22. I ran a short SMART self-test and no error was reported. This is the third time I've seen the message (the number is going up: 7, 16, 22) but have so far ignored it. First was in in February this year. Should I be concerned?

I tried deleting and then recreating proxynet, but that didn't help. Then I tried creating a new network, proxynet2. I assigned my Swag and Nextcloud containers to it and they seemed to be OK. Then I reassigned the containers back to proxynet and lo and behold, they're now working. To tidy up I deleted proxynet2. So far, so good. If things run fine for a few days, I'll mark this as solved.

I'm on 6.12.6. I ran into some problems that led to an unclean shutdown. I got some advice here to fix the problems, and followed those steps (switched from macvlan to ipvlan, recreated the custom docker network (same name "proxynet") and recreated the docker image. But now my docker containers (Swag and Nextcloud) aren't connecting to proxynet. Host access to custom networks is enabled, as is Preserve user defined networks. Searching a bit on the forum there did seem to be some cases of problems with custom docker networks not working after an unclean shutdown and possibly the Host access to custom networks setting being shown as enabled when in fact it had not been enabled. The suggested solution was to disable and re-enable this setting, which seemed to work in some cases. I've tried that, also rebooted and tried that again, and I still have the same problem. Here's what I have: root@Tower:~# docker network ls NETWORK ID NAME DRIVER SCOPE bd5116d783dc br0 ipvlan local a3b3aaa3ce56 bridge bridge local 83cf0e1b1ef5 host host local 9e74c89874cb none null local 69ed37939ece proxynet bridge local root@Tower:~# So it looks like proxynet is running? There was also a suggestion that the problem was caused by a race condition, where the docker container tried to connect to the custom network before the network was up. I tested that as well by restarting Swag, same problem. Then also tested by setting Swag autostart to off, disabling docker service, re-enabling docker service, waiting a few minutes and then starting Swag. Still had the same problem. Any suggestions on how to fix this? tower-diagnostics-20240331-2100.zip

I've switched to ipvlan, recreated the custom docker network (same name "proxynet") and recreated the docker image. But now my docker containers (Swag and Nextcloud) aren't connecting to the custom network. Host access to custom networks is enabled, as is Preserve user defined networks. I'm sure I've done this before, so I think I'm missing some obvious step. Here's the result of docker network ls: root@Tower:~# docker network ls NETWORK ID NAME DRIVER SCOPE 16453c5dced9 br0 ipvlan local 7c5d56aee35f bridge bridge local 83cf0e1b1ef5 host host local 9e74c89874cb none null local 69ed37939ece proxynet bridge local tower-diagnostics-20240331-1848.zip

Thanks so much. Will carry out the fixes once the parity check has completed.

The GUI has become unresponsive at least twice more in the last month. Not sure if it's the same problem, but would like to know if there's something obvious that I should be doing. Still on 6.12.6. This resulted in unclean shutdowns each time. Diagnostics and syslog are attached. Syslog is lightly redacted; hope I haven't removed anything that's pertinent. (\\IP address\Tower_repo is a Tailscale connection.) This time the GUI got stuck while updating the DuckDNS container - I saw some error message (unfortunately can't remember what now) and then the GUI gradually froze - various tabs became unresponsive. tower-diagnostics-20240329-1010.zip syslog-192.168.1.14.log

Just want to confirm: we can still buy current (Legacy) licences before 27 March at the prices shown, but that deadline doesn't apply to activation of the licence? In other words, I could buy the licence tomorrow and activate next year and not pay anything more.

I'm with @Sissy on this. For a long time I used an adapter to run the flashdrive off a USB header on the motherboard, so it was of course inside the case. Was quite happy until one day the flashdrive died. Then I had to open up the server to replace the drive. Much as I love my Fractal Design R5, for me the glass side panel is incredibly difficult to align (too much flex) and closing it up while it's vertical involves a bit of non-techie thumping. (I could place the server on its side, where replacing the panel is a bit easier, but my SATA cables seem to be quite sensitive, so didn't want to do that. Also, with 10 hard drives, it's not a trivial matter to move the server around.) I had to test a few times to find out whether the problem was with the flash drive or the adapter - I think in the end it was indeed a dying flash drive. But after that I thought I might as well just stick the flash drive into one of the USB ports on top of the case. At the very least there would be no worrying about whether the adapter was working. No one else comes near the server, and in my (untidy) situation, there are some many other things that are more likely to be dislodged or knocked over (ethernet cables, UPS cables, network switches and their power cords, etc.) One possible additional advantage to mounting the flashdrive externally, admittedly not tested yet, is that it might be useful if I have a dualboot server. On my other server, I have Win11 installed on an NVME drive that is passed through to a VM. Usually unRAID runs on the server and I access Win11 via the VM. The BIOS boot order is unRAID first, then the Win11 drive. A week or so ago, I managed to mess up the VM (I think when I tried to run WSL2) and could only access Windows by booting into the NVME drive directly. This meant fiddling with the BIOS to change boot device order so that I could boot directly into Windows, trying a Windows fix, and then resetting the boot order to go back to unRAID to test whether the VM was working. This had to repeated every time the fix didn't work, and I ended up having to do this a few times. I think that if I had had the flash drive mounted externally, I could simply have removed it, so that when the BIOS couldn't find it, it would boot into the next item, the Windows NVME drive. After that I could just plug in the flash drive again to boot into unRAID. Haven't tested this out because there hasn't been any reason to open up the case (another R5) to move the internally mounted flash drive). I'm sure there's a better alternative boot process involving GRUB or something similar, but I haven't looked into that.

I can't help on this specific situation, but I got passthrough working using the guide here: https://forums.unraid.net/topic/133563-gpu-passthrough-is-easy-heres-how/ I have a Win 11 VM and an nVidia GPU.

Well it so happens that I forgot to disable syslog server from some past investigation, so I actually have a syslog. I've removed earlier things and lines after rebooting, but can add those back if needed. Looks like the crash was around 3.00 am on Feb 24. syslog_1.log

This morning I found my server (6.12.6) had hung: couldn't access the GUI or the shares. IPMI showed an unRAID screen with a field for user name, but I couldn't type anything into the field, even using the virtual keyboard. In the end I had to reboot, so there was the dreaded unclean shutdown, and now parity-check is running. Don't think I've done anything drastic, although over the last few weeks fiddling with docker container access I switched from ipvlan back to macvlan and vice versa a couple of times, but the server has been running fine (on macvlan without any further changes) for at least a week. Hoping someone can make sense of the diagnostics and tell me what caused the problem. tower-diagnostics-20240224-0945.zip

Did I mention the great support in the forums? Now let me find something else to complain about.

I like saving money as much as anyone else, but where I am, the current Pro licence is roughly the cost of an 8TB hard drive. If I want to avoid subscription/extension fees and go for a new Pro/Lifetime licence, I'm guessing it will cost less than a 16TB hard drive (I currently have four in one array, two in another). Of course unRAID isn't perfect (I absolutely hate the clickfest Alerts/Warnings/Notices system in the GUI), not all my queries here get answered and I will never understand the difference between macvlans and ipvlans, but me and unRAID have come a long way since I wrestled with PATA drives and thought a 400GB drive was huge. I was going to say I'm not a fanboi, but actually I think I am 😀

Specifically re Firefox on Android on a tablet: when I use FF there is no tab bar, which I find makes it almost unusable. I did try an extension, but it could display tabs only on the bottom. Am I missing a setting? I'd love to be able to use FF on the tablet so that it can sync with my PC. I've seen occasional advice about not using FF with the unRAID GUI. Here's one I managed to dig up: In practice I've been using FF almost all the time with no problems, but have just kept in mind that if there's an unRAID GUI related issue it might be a FF issue.