kricker

I've installed GPTWOL, but when I try to access the webGUI, nothing loads. The log doesn't show any errors. It is set to run as network type: host. [2026-04-14 10:32:01 -0400] [9] [INFO] Starting gunicorn 25.1.0 [2026-04-14 10:32:01 -0400] [9] [INFO] Listening at: http://0.0.0.0:5000 (9) [2026-04-14 10:32:01 -0400] [9] [INFO] Using worker: sync [2026-04-14 10:32:01 -0400] [9] [INFO] Control socket listening at /app/gunicorn.ctl Launching GPTWOL...

Thanks. I'll need to dig into that. It broke again. Connect is "working" but only if I am in my local network which is useless.

As the title states, it appears the Connect plugin knows when I am out of town and need to manage the server, and thus quits working. I can never figure out why it is no longer connected. When I can finally get back into my server, I reconnect it, and then I have to go back through a series of prompts registering my server every time. It is so unreliable. What can I do to get this more stable? I've removed the plugin, re-installed it. Totally gone through and reset all the settings multiple times. Then, when I think it is working great, I leave town and BAM, it's f#@# not connected again.

Same for me. I can't seem to ever keep it working properly. Works for a day, then I am no longer signed into unraid.net. Now I can't even get the logo to show up in the top right corner. I have tried uninstalling and re-installing the plugin. It is very frustrating. Just when I need to use it, it never works.

Oddly enough it is that Promise controller now having issues with unRaid in V7. Everything was working fine with the cache drive connected to the onboard controller in 6.12.14. i upgraded back to 7 and again everything was fine. I ran it since my last post with no issues. Yesterday I shutdown and swapped it back to the Promise controller. Upon boot I saw the slow link warnings. I shut it back down. Swapped to yet another new cable but still using the Promise controller. Once it booted, the cache SSD was missing. I had to move it back to one of the onboard controller ports. Strangely, I still have drives 1 and 2 connected to that controller, but they are not having any issues that I am aware of.

I have two other drives on that promise controller. I don't recall them disappearing. So my hunch is it's just that SSD decided to finally take a dump.

As mentioned above. I have replaced the SSD with a new one. I cloned my old one to a new one and swapped it out. I am testing things now. I guess this was all just coincidence after upgrading to vs7. I have dropped back to 6.12.14 for now.

That was after a cable swap and moving it from the onboard controller back to the promise SATA controller. I now cloned the Cache to a new SSD and swapped it out. I did see that limited speed warning on boot even with new SSD on the Promise SATA controller and it would not even show up in the webGUI when I booted. I shut down again, moved the Cache to the onboard controller and had no warning about the link speed this time. I was able to assign the new cache drive. So I will see how it goes now. If it is stable. I will move it to the Promise controller again with yet another new cable and see what happens. Interesting when the Cache drops offline it takes the user shares with it. I guess that makes sense as those shares are all set to use the cache drive. Oddly I do not get any warnings/alerts in the webGUI and when it drops offline I still see it in the webGUI assigned in the cache pool. I have to to a lot of clicking back and forth through the tabs refreshing to see if it disappears. Several times it never did and always showed as assigned.

It just happened again and I lost all but two shares in the webGUI. I grabbed the diagnostics immediately. tower-diagnostics-20250124-1149.zip

Will do. I am testing cables, controller card, etc first to rule those out first.

One day after updating to unRaid 7, I began having issues. At first I noticed shares were no longer accessible through SMB. When checking the webUI I saw these shares were now not even listed. After checking the physical disks I could see that the folders and files were still there. After a reboot things would work again for a few hours and then it would happen again. At this point I noticed that my dockers would crash. Apparently something may be happening with my cache drive. Any share that had data on the cache drive would disappear from my shares list. Possibly a failing cache drive that by coincidence started failing after updating to 7? tower-diagnostics-20250123_1517.zip

I sent you a message. I can try to give you a hand without sidetracking this thread.

I have switched over to the SFTPGo docker. Took a moment to setup, but it has been working great. I really like the web interface for the non FTP savvy users that sometimes need files from me.

Okay. Thanks. I did shutdown all the dockers and it was still running. I forgot to test the plugins.

It is bouncing around between 2 and 30 percent constantly.

I noticed I have several of these commands running all the time. One in particular is always hitting the CPU. /usr/local/bin/shfs /mnt/user -disks 1023 -o default_permisssions,allow_other,noatime -o remember=0 What is this?

I've not tried to set that up and didn't even know what yt-dlg was until I just Googled it, so unfortunately I have no clue for that.

Have you used the information from @DaveHavok? Mine has been rock solid since then. It is currently at 5.0.3 build date 2024-03-02.

I had the same issue and then ended up just redoing the docker container from scratch using the information above from @DaveHavok, and then the note above from me.

I have been having the connections issues now as well. I have totally started from scratch to experiment. I have found that if I remove the password as stated by @zarkoff it will connect once. If you restart the docker and try to connect again it fails. I then have to re-add the password, start the docker, stop it again, then remove the password, restart the docker then I can connect again. I seem to have to repeat this if the docker ever has to be restarted.

Yeah, that may suck, I'd keep a backup of the settings file and database files. Maybe you can swap them out once it's back up and running again.

Did you also delete its folder in your appdata share so that you re-set it all up from scratch?

I'm stumped. Maybe remove the docker and Re-install it?

How about the Docker or whatever is placing files in your media location? Maybe it has different permissions/user/group set. My umask is also set to 000, which I believe is the default. Mine just updated to 4.3.13 and is working just fine as I just did a set of renaming/moving and meta data adding.