Dyon

I also have issues with the Palworld container at the moment. I restarted the container to get the v0.1.3.0 update, I even have validate files set to `true`, but the server ain't updating. I even removed the Palworld server Binary files (/palworld/Pal/Binaries/Linux), but it still didn't validate or update. Currently completely removing `steamcmd` and `palworld` from appdata and restored a save backup to see if that fixes something.

It should be the path below Sync Location, which is /mnt/user/appdata/owncloudcmd/ by default, which is the path on your Unraid;

@Frank_B Keep SILENCE_OUTPUT on 0, and check the unraid appdata/owncloudcmd/latest.log The logging function is kinda written shitty by me, so it keeps overwriting itself every run, which is 30 by default. Set RUN_INTERVAL to 300 and check the log after a couple seconds. In this log file you can see if there any any obvious error messages. If sharing parts of the log, make sure to remove any personal info. Something else I want to point out is that the version of owncloudcmd used by my docker runs version 2.11.1.8946 released 18th of August 2022, while the newest version 5.2.0.12726 is released on the 28th of November 2023. This MAY be a reason that it does not work for you. The reason I did not update the version beyond 2.11.1.8946 is because I just couldn't get the newer versions to work, and the old version was still working fine (and still does for me). I might give it another shot in the future.

@Frank_B Config seems fine to me, matches mine. If you visit the OC_SERVER + OC_WEBDAV URL in your browser, you should get a simple authentication prompt from your browser. If you login using your OC_USER and OC_PASS, it should display 'OK' (atleast for my owncloud implementation). OC_SERVER + OC_WEBDAV URL is owncloud.?????.de/remote.php/dav/files/??????????????????????? If ??????????????????????? is your username, I don't think you need to include that.

Looks interesting, whenever I have time I will look into it

Can confirm issues with WireGuard for unknown reason. However, I am sad to inform that due personal circumstances and shifts in interests I will not be updating the container in a timely manner. Even though I prefer WireGuard over OpenVPN, for now I sadly would need to recommend using OpenVPN, that one works fine.

My bad, the sorting on my filesystem was sorted the wrong way around. Attached are the proper diagnostics. I naturally did a clean boot without the packages installed. dyon-unraid-diagnostics-20230702-2131.zip

Thanks for the tip about the `extra` directory. I know using Docker etc is better. But I ain't gonna install a Docker only to run `nmap` for something or when I need to use `ffmpeg` to quickly convert a file. Nevertheless, the problem still occurs with a clean `go` file. (cc @Squid ) Still need to kill -9 nginx and start it again for it to work. Also running 6.12.2 now. Same problem. nginx-error.log dyon-unraid-diagnostics-20190307-1931.zip

I know you mentioned that you are sure that the username and password are right, but this line in the log really means it could not be anything else: 2023-06-28 21:49:45 AUTH: Received control message: AUTH_FAILED Please check again your NordVPN dashbord under the option Setup NordVPN manually; https://my.nordaccount.com/dashboard/nordvpn/ This guide is for Android, but the process of obtaining the NordPVN credentials are the same.

Will run a clean go file later. I honestly don't expect that the extra packages impact the WebUI personally. I haven't changed anything in that file for about 2 years honestly. The docker logs hack is an older version of this below, didn't even know that I still had that active or why I needed this. I am currently of a big upload via FileZilla, so I can't sadly interrupt that to tes if a clean go file fixes it.

Waited about 30+ minutes. I think php-fpm probably broke, so running PHP was not possible. Using kill -9 on nginx I was able to kill NGINX and also by running I was able to connect to the WebUI: /etc/rc.d/rc.nginx restart /etc/rc.d/rc.nginx reload /etc/rc.d/rc.php-fpm restart /etc/rc.d/rc.php-fpm reload /etc/rc.d/rc.nginx stop just didnt kill the proces... After that I was also able to run diagnostics, which took literally 30 seconds indeed. I also had a `cat /var/log/nginx/error.log` open before shutting down the server. I dont think it's included in the diagnostics. It's not the full log file, but only as much as my terminal could show. Forgot to pull the actual file of the server. dyon-unraid-diagnostics-20230627-1520.zip nginx.log

I am on Unraid 6.12.1. I also am unable to access the WebUI after some time. It does work initially, but after having the GUI open for some time, I notice it stops updating and becames inaccessible. Everything else just keeps on working fine, but it's just the WebUI being dead. Rebooting the servers via SSH works. After reboot the WebUI works again. If I SSH to my server and run `diagnostics` it just hangs... I also don't see anything getting added to /boot/logs. What can I do? Should I upload diagnostics AFTER a reboot when the UI works maybe? I have 2 NICs, via both ports I am still able to access shares or SSH. So there is a link.

Don't see anything wrong with the docker run command. Perhaps it is the Wireguard file itself. Please download a wireguard client for your PC and see if connecting works properly that way. https://www.wireguard.com/install/

Try removing the container, maybe that works And than add it again

That's odd. The windows continuously closing because it is probably unable to connect to the HEALTH_CHECK_HOST. I've pushed an update to the container which adds RESTART_CONTAINER. Update the container and add the new variable. This will prevent the container from restarting To add this variable, edit the container and add this variable: Add another Path, Port, Variable, Label or Device > Config Type: Variable > Name: RESTART_CONTAINER > Key: RESTART_CONTAINER > Value: 0 > Default Value: 0 > Description: (empty) > Display: Always > Required: No > Password Mask: no After changing this, start the container, open the console and please check if you can run the command `ping one.one.one.one`.

Oh, if username must be lowercase, I can make a check for it

Due to loss of interest in maintaining the Docker container, this project is no longer being worked on, and no updates can be expected. If requested, a new container build for a new version of SABnzbd can be created. However, if the new version of SABnzbd requires additional dependencies or the build fails, I will not fix it, even if it's minor. Just to make sure, I built a new container to ensure it's up to date. I didn't check if there was a new version; I just started a new build for the sake of it. I recommend switching to another SABnzbd container that has VPN capabilities and receives regular updates and better support.

Due to loss of interest in maintaining the Docker container, this project is no longer being worked on, and no updates can be expected. If requested, a new container build for a new version of nzbget can be created. However, if the new version of nzbget requires additional dependencies or the build fails, I will not fix it, even if it's minor. Just to make sure, I built a new container to ensure it's up to date. I didn't check if there was a new version; I just started a new build for the sake of it. I recommend switching to another nzbget container that has VPN capabilities and receives regular updates and better support.

Thank you! Went with method 1 since that is the easiest

What is the process for managing the depreciation status of some of my own applications on CA?

At the bottom there should also be an option to add a new variable, path or port. You can enter a new one for RESTART_CONTAINER. I don't think restart unless-stopped has an impact on this.

Check the advanced settings when editing the container. There should be an environment variable RESTART_CONTAINER, set this to 'no'

Mine has always been orange and I never bothered to look into it hahahaha, never had problems downloading or connection issues

Very odd. Nothing has changed to the container since February. Iy only auto-updates / rebuilds whenever a new Jackett version has been released (which fixes indexing trackers). Nevertheless, I will investigate and look into what could be wrong. Which Unraid version are you running @Skyshroud and @xcsascii?

It is normal that your local DNS is listed in there, so no need to change that. You are running it in Bridge mode, which is correct, which I can see from the log Looking extensively at your log, I don't see anything different compared to mine. Kinda out of ideas, only I could suggest now is to restart your Unraid and check your Docker and Network settings. In Unraid, can you check if Settings -> Docker (show advanced view) -> IPv4/6 custom network info makes sense. For comparison mine: IPv4 custom network on interface br0: Subnet: 192.168.0.0/24 Gateway: 192.168.0.1 IPv6 custom network on interface br0: Subnet: 2001::a300::/64 Gateway: fe80::eaa5 For all DHCP pool: not set And also, check you Settings -> Network Settings Here is my routing table for comparison: