terag1e

Worked perfectly! Thanks!

I have recently begun to experience significant issues with the screen display in Unraid GUI. I have attached a screenshot of my docker page. The "bottom" section where you can say stop all, start all, update all, etc. is suddenly appearing at the top of the screen and is not responsive to clicks. The biggest impact so far is I can only update my dockers one at a time. The issue also exists on my VMs page. I thought it might have been an issue with my older version of Unraid - 6.12.10, so I used it as an excuse to finally update to 7.1.4. Still having the same issue. I can provide any diagnostics if needed. Any ideas as to what the issue is or where to start troubleshooting?

The simplest resolution I have found is to add a line in your hosts file (Windows/system32/drivers/etc/hosts) with the local IP address [Tab] Name of your server The file has to be edited with administrative privileges (right click on Notepad, run as administrator). I do not know if syntax and spacing are critical (use spaces instead of tab?). I have multiple VM's that started having issues with accessing the shares. In every case, it was resolved by adding IP address (local) and Name of server in the hosts file. I also have always had a username setup in my Unraid with the same username/password as my Windows credentials. Hope this helps.

I've attached two files the progress.save file and the parity checks log. I run the plugin to run from 1AM until 8:30AM and when a host of disk intensive backup activity completes around 9:30, I usually hit resume. On this run, since there were two backup windows, I also paused manually around 12:00P. There seems to be some oddities in the lines, because I only run the plugin, but it seems to be making a distinction between automatic or scheduled and manual which may be creating multiple entries. Any help would be appreciated. My 'calculation' from the progress file should be in the 110-120Mb/s I believe. parity.check.tuning.progress.save parity-checks.log

Is that file just appended to with each parity check? Or is it rewritten fresh for each parity check. I will likely wait until my next scheduled parity check (first of Dec) and let the current settings I use for the tuning plug-in be used. Are just the parity-checks.log and parity.check.tuning.progress.save files the ones needed? I currently have the Parity Check Tuning logging set to Basic. Should that be set to something else (Debug or Testing)?

Continuing saga: Beyond having to rebuild the server (YAY) the last manual parity check I ran still appears to have incorrect timing calculations for running time and total time. I have attached the relevant entries from system log and parity check log. For the parity check in question, the elapsed time (by log entry) is just short of 2 days, yet is displayed as nearly 3 1/2 days with similar error in the running time. This particular parity check had 4 pauses. When there are no pauses in the parity check, the times appear to be accurate. The incorrect times calculation directly impact the MB/s metric. Parity Check Tuning log entries.txt

Once again, thanks for the help. It certainly worked for a few months. In my October parity check it only captured one increment which is very much not the case. I was trying to move the parity check along, so I resumed during low server activity periods during the daylight hours. It made it through the parity check a bit faster than just the few hours each night which was my goal. However, the history now only shows one increment (there were at least 3 and likely 4-5), so the speed calculation is WAYYYY wrong! I only wish I had that speed! At any rate, if there is anything I can provide, please let me know. I have had to restart the server, and am currently in the process of rebuilding a drive - so things captured in the server log (Unraid) may have gotten lost in the restart shuffle. Again - love the plugin! I run a few VMs and they would always begin to suffer terrible lag when parity checks were active. Now I just run the parity checks during my sleep hours and the VMs run great!

Thanks @itimpi. That indeed works and all of my recent history displays now! Thank you for the help!

Glad that it may be of help!

Thanks. It does look like the parity-checks.log file has some very strange format shifts throughout. I can't say when the history stopped displaying, although I thought it began when I installed the plug-in. Of course, it may have been when I upgraded to 6.12.10......or it may have just been ill fortune for whatever reason. I've attached the log file. Thanks for taking a look. parity-checks.log

The History button does not display any content. The data is still there in /boot/config/parity-checks.log. I checked the system log and found the latest entries for Parity Check Tuning which indicated: Aug 5 10:21:00 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 1: Aug 5 10:21:00 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 2: Aug 5 10:21:34 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 1: Aug 5 10:21:34 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 2: The last few lines of parity-checks.log 2024 Aug 5 03:14:06|132684|120.6 MB/s|0|0|check P|15625879500|341486|3|Scheduled Non-Correcting Parity-Check And the lines in the system log associated with parity check tuning: Aug 5 03:18:21 Tower Parity Check Tuning: Scheduled Non-Correcting Parity-Check finished (0 errors) Aug 5 03:18:21 Tower Parity Check Tuning: Elapsed Time 3 day, 22 hr, 51 min, 26 sec, Runtime 1 day, 12 hr, 51 min, 24 sec, Increments 3, Average Speed 120.6 MB/s Aug 5 03:18:21 Tower Parity Check Tuning: Send notification: Scheduled Non-Correcting Parity-Check finished (0 errors): Elapsed Time 3 day, 22 hr, 51 min, 26 sec, Runtime 1 day, 12 hr, 51 min, 24 sec, Increments 3, Average Speed 120.6 MB/s (type=normal link=/Settings/Scheduler) The parity check tuning plug-in appears to be working. The task completes and entries are placed in the system log. However, something seems incorrect with the entries in parity-checks.log. I can attach the actual logs and/or settings if needed. I would really like getting the history back to being displayed if possible.

On this continuing saga that is becoming much more of a thorn than a nagging issue. The random freezes are now happening more frequently. I have narrowed it down to highly likely something to do with how I set up my Win11 VMs. I have one that is running and has been running without issue since before i upgraded. I did update the virtio drivers, guest-agent, and machine type. This VM setup used the old Win10 template, so I did not use OVMF-TPM, just OVMF. On all recent VMs with Win11, I have tried with and without TPM, from the initial setup/install. Continued random, but now quite frequent machine freezing. I used the Win10 template in the new Unraid VM section, still the same result. I even went so far as copying the xml for the one Win11 machine that is working well, changing the necessary parameters (network, mac address, VM name, vdisk location, etc.) and wound up with frequent freezes again. I have allocated up to 8G memory. I have pinned two cpu/threads. All continue to randomly and frequently freeze. I turned docker services off. Same issue. I tried changing network adapter to e-1000. No joy. I made a new Win10 machine with W10 template. NO ISSUES thus far, and as many times as the other W11 VMs freeze (and frequency), this is certainly the fall back position. Other than the single W11 VM I have that's been working since before the upgrade, this most definitely seems to be some error in my W11 VM setup. My motherboard is too old to have TPM (upgrade planned but not yet executed). To this point I've just been using the "modify the registry" to bypass hardware checks for TPM on install. Wit's end on troubleshooting! Frustration compounds.

I did isolate and pin 2 cores to the VMs. They still randomly freeze, requiring a Force Stop. The last bit of detail I've come up with is the whole macvlan vs ipvlan mess. I've been with Unraid for quite some time, so I guess I started on macvlan. Now the default is ipvlan. And with bridging enabled for dockers and VMs this seems to cause issues with some hardware. I have yet to change the dockers to ipvlan. I have an ecosystem of *arrs that can get finicky with network settings, so I'll have to study up on the potential pitfalls. I've come to learn, it's hardly ever as simple as 'flip the switch' and no unintended consequences. To summarize: Still getting VM freezes requiring Force Stop with 2 cores isolated AND pinned to the VMs only. My next steps are to weigh downgrading Unraid back to 6.11.5 to see if the VMs are still freezing (they did not before the upgrade to 6.12.10) OR take the plunge and change docker engine to ipvlan, leaving VMs with bridging, and deal with the *arrs potential issues.

isolate the core or pin the core in the xml? I have cores pinned in the xml already. I'm reluctant to isolate cores as I've seen references to the fact it harms the vm cpu performance. I'm not passing through any graphics adapters. However, I am running pretty consistently 4-5 VMs that are constantly on, none are tremendous cpu or memory intensive. I've got 32G memory in the server and Xeon® CPU E31240 (4c/8t). I am in the process of upgrading the server hardware throughout the rest of this year, but I'd rather get all the nits and niggles resolved before subjecting everything to newer, better hardware (cpu, memory, MB). I'm also attempting to basically re-make the VM, using the W11 template in 6.12.10 using all the latest virtio drivers and changing machine type to Q35 (as I've heard that machine type is better suited to TPM and W11. Thanks for the suggestion! I'll put it into my research to helping to stop this nagging issue of random vm freezes requiring force stops.

I recently upgraded from 6.11.5 to 6.12.10. All of my VMs have been working flawlessly for the last year or more. After the upgrade, most of my VMs would have random freezes requiring the VM to be force stopped. The situation occurs multiple times during a 24h period. i have updated the templates to the latest virtiofs drivers iso - 0.1.248-1 and the machine to i440fx-7.2. I have tried to rebuild the template from scratch using the templates in the new Unraid version and just attaching the vdisk to that template. No go. I am at a loss at where to even begin to start looking for root cause of the issue. I like to stay current on the unraid server version and finally took the leap. Do I or should I downgrade back to 6.11.5?

I just upgraded to 6.10.12 6.12.10 from 6.9.8 6.11.5 All of my VMs start, I can interact with them through VNC. However, they randomly freeze, requiring a Force Stop of the VM and a restart. I have upgraded the virtio driver iso to the latest 0.1.248 and updated the machine in the setup to i440fx-7.2. I am still getting random freezes of the VMs (all Windows 10 or 11). =====EDIT===== This was AFTER upgrading to 6.12.10 FROM 6.11.5. Apologies for the inaccuracate versions. I have also tried rebuilding the template from scratch using the new built-ins in the new Unraid version, and pointing to the existing disk of a machine that continues to have this issue. That did not solve the problem. ====END EDIT========== How do I go about troubleshooting this issue?

FWIW: I have never in my online experience spanning decades, seen the following: signed in as an authorized user (password, username (email)) having provided credentials. Do your thing - scroll through the blog, web-pages in the domain, etc. LOG-OFF SUCCESSFULLY - the screen even said so. Close the browser, re-open the browser, go to the web-page requiring some sort of sign-in ----- and, drum rollllllll --- you are STILL LOGGED IN! I'm sorry not even a 256 character password is going to work in that scenario. Looks like help is needed in a flawed rollout, even if it is to "a small percentage of our user base."

I got signed in, changed password and everything appears to work as intended. Whilst I was changing things, I also decided to change the email address associated with the account. Unfortunately I get caught up in a vicious circle - change email, requires to re-authenticate, which uses the old email, the screen says the email was changed, I get an email change notification at the new e-mail), but it will only accept my old credentials when re-logging in. Rinse and repeat. No joy.

And I may yet! I have quite a few VMs throughout the network, but right now it's a problem for days in the future (thin client)!!

One of the reasons I have stuck with the 1.3.15 version of deluge is its ability to use the thin client, which I far prefer over the web client. But progress moves on, and I far prefer having the port forwarding OpenVPN with PIA, so a small price to pay. (And the legacy servers are retiring at the end of the month!) I do have a question, however. I force upgraded the newest binhex image, set it up, everything works pretty spontaneously. Thanks for all the quick, hard work, binhex!! The connection to CA Toronto resulted in a port forward connection. I can see this through one of my torrent providers that reports back if your seed is port forwarded. On the thin client, I could press a button on the Network tab of Preferences to "Check Port", which would always show a green ball if the port was forwarded or a yellow triangle/exclamation if not. Since there is no thin client in this version of deluge, and the web client on Network tab of Preferences does not have this, just a filled in port number, my question is this: Is there a way to determine if port forward is active on the connection? Can I inspect either supervisord or through the console window for the docker to easily confirm port forwarding is active for the torrents in the client?

Mine is currently Key 6 in the config screen with a container variable: STRICT_PORT_FORWARD, but it is not a drop down selection. you have to actually type in the setting (yes or no). Don't know enough to know whether or not the Variable name needs to be the same, but mine is Variable name: Key 6. Re using the port forward endpoints, I have had success with STRICT_PORT_FORWARD = no, still using the Canadian servers that I knew were portforwarding before all this, but then manually entering the port forward port in the settings in my stand alone deluge gui app (not web-gui). The port is definitely not forwarded as I can check that on a torrent site that I have active torrents on and it displays whether or not the current connection is port forwarded (it's not). But my speeds don't appear to have taken a huge (or any) toll. But I also haven't taxed the client much in the last couple of months.