CoZ

So I let that command / open terminal window sit there for 2 hours or so. Nothing happened at all. All those log files are still in that directory.

So you are suggesting to copy/paste that above command into the terminal of UnRaid or, the terminal of the container? I've manually opened the .unamanic/logs/buffer directory and I have files in there from 2025..... So I went and copy/paste your above command into a terminal window in UnRaid and hit enter. It's been about 30 minutes now. I can no longer access any of my UnRaid shares over the network, it just "times out". I still have access to the UnRaid webgui though. So perhaps it's due to this command running causing it to time out over the network. However, this is making me very nervous LOL I've gone from waiting for 10-15 minutes for this container to start up to, now, hours of waiting for the container /WebGUI to start.

You are correct. It IS starting, but it takes (I think) even more than 10 minutes - on my system anyway. May have different spin uptimes for different hardware? I just know it's never done this before. It was instant.

Well that makes me happy that I am not the only one here with this strange issue.

Well, magically, after letting the machine "sit" overnight, I came back to it earlier today and was able to start the Docker service. I didn't touch anything, I didn't reboot the machine. I spoke nicely to it and softly petted its chassis before attempting to start the docker service. lol I had to restart a few containers after everything started back up. Other than that, everything is fine. No idea what caused the issue. No idea what occurred overnight that let me start the docker service either.

I was having multiple issues with the Docker.img when someone on /R/UnRaid suggested changing it to docker folders. This is the first issue I've had since the switch from IMG to folder. Thanks for your reply though as you're the only one whom has replied.

cozsnas-diagnostics-20250916-1950.zip Was updating IMMICH. At the end of the update progress it stated "Error" and then my entire docker service went down. I've toggled Docker service on and off multiple times and it won't come back up. Tried to do a normal reboot - after about 10 minutes of waiting for the system to stop the array and unmount disk shares, I did a hard reboot. System is back up as normal and started a parity check as normal. However I still can not start the docker service.

I'm unable to access the Web GUI after the latest couple of updates. Usually a restart of the container multiple times kind of "kicks it in the pants" and allows me to access the Web GUI. However, after today's update was pulled/pushed, multiple restarts of the container and I still can not access the web GUI. Checking the logs all I have is pasted below. Anyone have any ideas as to why this is happening? Or, is anyone here suffering the same issue? [migrations] started [migrations] no migrations found **** (permissions_config) Setting run user uid=100(abc) gid=99(abc) **** [migrations] started [migrations] no migrations found **** (permissions_config) Setting run user uid=100(abc) gid=99(abc) **** usermod: no changes ─────────────────────────────────────── _____ __ __ _____ _____ _____ _____ | | | | __|_ _| | | | --| | |__ | | | | | | | | | |_____|_____|_____| |_| |_____|_|_|_| _____ __ __ _ __ ____ | __ | | | | | | \ | -| | | | || | | |_____|_____|_|_____|____/ Based on images from linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── usermod: no changes **** (permissions_config) Setting permissions **** [migrations] started [migrations] no migrations found **** (permissions_config) Setting run user uid=100(abc) gid=99(abc) **** usermod: no changes usermod: no changes **** (permissions_config) Setting permissions **** ─────────────────────────────────────── _____ __ __ _____ _____ _____ _____ | | | | __|_ _| | | | --| | |__ | | | | | | | | | |_____|_____|_____| |_| |_____|_|_|_| _____ __ __ _ __ ____ | __ | | | | | | \ | -| | | | || | | |_____|_____|_|_____|____/ Based on images from linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100

Are you trying to use it behind a VPN for "privacy" or, you are trying to use it behind a VPN to connect to it? I mean, are you trying to use unraid tailscale / wireguard to connect to it without exposing it to the internet or are you trying to expose it to the internet AND use a VPN to 'protect it'?

For those of us here using Invoice Ninja - does your container stop all by itself requiring a manual re-start of the container? I can't find anything in the logs as to why my container is stopping all on its own. There is no rhyme or, reason to it... sometimes it will go months without stopping, and sometimes it will go weeks. It doesn't stop after an update is applied, I've watched and applied an update manually, and it restarts itself with no issue after the container has been updated. It's becoming troublesome for my small business owner friend whom I am hosting it for....

Update: Fixed! (for me anyway) Looking at @jayare post about deleting the cookie in Chrome, I did the same in Firefox. Deleted all Cookies associated with my UnRaid's IP. Now the torrents don't "blink out" after restarting Firefox. I will throw my name into the hat as well with all my .torrents blinking out of the screen while using Firefox. It's damn strange though because on my laptop, using Firefox, I don't have the issue. Same version of Firefox between both my laptop and, desktop where they "blink out".

I'm not getting anything back at all in the CLI

Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): YES Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes Found `Nuvoton NCT6798D Super IO Sensors' Success! (address 0x290, driver `nct6775') Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... Yes Found unknown chip with ID 0x0101 Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): YES Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): YES Probing for `National Semiconductor LM78' at 0x290... Success! (confidence 6, driver `lm78') Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): YES Found unknown SMBus adapter 8086:43a3 at 0000:00:1f.4. Sorry, no supported PCI bus adapters found. Module i2c-dev loaded successfully. Next adapter: SMBus I801 adapter at efa0 (i2c-0) Do you want to scan it? (YES/no/selectively): YES Client found at address 0x51 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip) Client found at address 0x53 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip) Next adapter: i915 gmbus dpa (i2c-1) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus dpb (i2c-2) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus dpc (i2c-3) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc1 (i2c-4) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc2 (i2c-5) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc3 (i2c-6) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc4 (i2c-7) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc5 (i2c-8) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus tc6 (i2c-9) Do you want to scan it? (yes/NO/selectively): yes Next adapter: AUX C/DDI C/PHY C (i2c-10) Do you want to scan it? (yes/NO/selectively): yes Next adapter: AUX D/DDI D/PHY D (i2c-11) Do you want to scan it? (yes/NO/selectively): yes Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `coretemp': * Chip `Intel digital thermal sensor' (confidence: 9) Driver `nct6775': * ISA bus, address 0x290 Chip `Nuvoton NCT6798D Super IO Sensors' (confidence: 9)

So, I've tried to do my homework and follow along in this thread for a while. 170+ pages gets a bit overwhelming. I've run the sensors-detect and gone through all the steps and now I'm presented with this last bit of info: Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): yes Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors for initialization at boot time. You should now start the lm_sensors service to load the required kernel modules. How do I start the lm_sensors service??

Changed it back to 8080. Left Variable: WEBUI_PORT:8082. Restarted container Typed into browser IP:8082 - this time it doesn't time out or, refuse to connect, I just get Unauthorized Found the solution: https://github.com/linuxserver/docker-qbittorrent/issues/243 added that line to the .conf file and now I am in the login screen.

Pulling my hair out over here. Port 8080 was in use for SABNZBD. Changed the Port: Web Interface: 8082 I then scrolled down and changed Variable: WEBUI_PORT: 8082 I can't connect to the WebUI in either Firefox nor, Edge. I am running the container in bridge mode. I've tried it with VPN ON and VPN OFF makes no difference. Connection times out. I can go to my client area in AirVPN and see that the Unraid server has connected to the service so it has to be up and running? I just can not access the WebUI no matter what.

Frigate. The bane of my exsistence. I barely have it up and running because it is difficult to figure out. I will try to Google how to limit it's RAM usage (and then probably implode the Frigate instance by trying to fix it) Thank you for responding.

Well a week has passed by with no one from UnRaid looking at this at all. The only download to my DIAG file was myself to make sure it works. Other than that, no help - at all.

It told me to capture my diagnostics and post them here. So, that is what I'm doing. cozsnas-diagnostics-20250216-1247.zip

Thanks. I was having the issue as well. Deleting those files and re-installing the plugin allowed me to reconfigure everything and have it actually work.

Thank you. Works perfectly now. I can't believe you STILL haven't bought the game though lol

Thanks for the quick reply. So besides backing up the enshrouded_server.json and the savegame directory - anything else? I'm not using the Proton Version.

Decided to turn this back on after months of not playing since I heard there was a new update. Anyway. Usual story, game wasn't showing up on the Server list. Re-start container, wait a few hours, still not showing up. Connected via IP address and got back "version mismatch, server too old" (paraphrasing of course) Restarted container because usually that's supposed to pull down the newest/latest update that way? Nope, same error message. I've restarted container and also stopped and started a bunch of times and for whatever reason, I'm not getting the update. Checked the logs and see only this:

I've never heard of it explained like that before. LOL! You're not wrong though. 'two arrows pointing to each other'. lol Not laughing AT you - just laughing because I never thought of it that way. Screenshot attached. The top info displays the drive and read/writes FileSystem. The bunch of numbers underneath it shows none of the reads/writes but is 'clickable / browsable'

I could not find a "double arrow" icon but I did see a "refresh" Icon. I clicked it and the mount icon was selectable. Thanks. Is there a reason why there are two devices listed for the one drive? Both show the correct size (1TB) but only one is browsable and only one shows the reads and writes to it.... Just curious.