tetrapod

Hia! My YouTube-DL doesn't have an icon I'm getting this to the log-file: YouTube-DL: Could not download icon https://raw.githubusercontent.com/SmartPhoneLover/unraid-docker-templates/main/templates/icons/youtube-dl.png ...and getting a 404 when looking for the file. No biggie, but could you have a look or tell me what I'm doing wrong?

While executing the commands from the same answer you were looking at I have time over I see that @blaine07 already answered your question, but I think he is missing what you are asking about. A command line window can be opened from the top right corner of the Unraid GUI >_

Thanks for caring. I never found out what the problem was and started to set the clock manually. I know, it's not good enough, but there are only so much risks you are willing to take with remote (like four country borders away remote) systems. Anyways, checking now and it seems that somewhere between 6.9.2 and 6.10.5 this fixed itself. It's working now. Could have been a corrupt config file that @John_M mentioned that is now overwritten... Thanks for adding you five cents

Did restart normally, but didn't do any difference for unraid GUI access Yes, that did start the reboot command, but I lost the prompt and all services seemed to be still open. I could see the disk-activity lamp plinking through the PiKVM interface I waited an hour and no difference: ...so used ssh in and did another reboot which did reboot the server, but triggered the parity-check 😐 After this I did manage to get the GUI, but not through the https://www.xxxxxxxxxxxxxxxxxxxxxxxxxx.unraid.net:<port> I had to go through http://<WAN IP>:<port>/ Now I upgraded to 6.11.5 which went well, but still the behavior from above. I changed to the new myunraid certificate and that helped. Now I could get the GUI from my servers page. Still couldn't get VPN access through my WireGuard tunnels, but after a while I realized I had to update the the tunnels after the URL changed. Yes, I do. I'm reading up on this and will m a y b e change it. Need to breathe first a couple of days. My old man heart is not built for remote updates It was the latest. Got uppdated automagically somewhere along the way. Thank you for the quick help and have a nice weekend.

Thank you so much for being thorow in your reply. I'll will have a look tomorow and tell you here how it goes.

Thank you treebeard-diagnostics-20221201-1029.zip

I can no longer reach my servers Unraid GUI. It worked just fine a couple of days ago. If I click [Remote access] I'm directed to the URL https://www.xxxxxxxxxxxxxxxxxxxxxxxxxx.unraid.net:<port>/Dashboard where I get a 500 Internal server error from nginx I have a wireguard tunnel active from where I can remotly reach the GUI of active containers via this URL format http://<server LAN IP>:<port>/ I can also reach services like SMB via the wireguard tunnel, but not the Unraid GUI like I could before via https://<server LAN IP>/Dashboard I get the same 500 Internal server error from nginx What can be wrong? I do at the moment have access to a shell via a connected PiKVM, but do not want to do an unessasary restart and what to find the root of the problem. The server is geografically located in another country and I'm terrified to do something stupid.

That's really good to know - thank you.

Back up again thanks to reboot via PiKVM (prais be it's name). Waiting for 6.11.2 before I touch anything more with network involved. VPN was now able to start without any changes to the config file. Marking the issue as solved

Thank you for providing a solution. However, I applied this without thinking :-$ Not your fault, but I think I cut of the branch I'm sitting on. Got to the [Apply] and then lost communication with the server that is four country boarders north of me. I have a remote access to monitor and power button through a PiKVM, but I'm afraid to order a reboot. Do not know what I could have changed to make this happen?!? I shouldn't have changed anything when hitting [Apply]. But maybe I did? I (think) I chnged one of the top Yes/No switches - something "* binding" - from Yes to No and then back again befor hitting [Apply]. Could that have changes something else? Can I check a settings file somewhere?

Have a workaround for this here, but still needs correction

Well, when WG is running it is very stable. Extremely so imho. To me it seems the error lies with UnRAID's WG config implementation in 6.11.1. I think it's an easy fix but we prabably need to wait for 6.11.2 for that. The workaround is stable

I have the same problem after updating 6.10.3 -> 6.11.1 Figured out a workaround

This is driving me nuts and I think I have figured it out. At least I can get it work, but maybe I do not understand all the implications. In the file /etc/wireguard/wg0.conf there is this line PostUp=ip -4 route add 192.168.100.0/24 via 192.168.100.1 dev table 200 The same line that throws the error in wg-quick.log [#] ip -4 route add 192.168.100.0/24 via 192.168.100.1 dev table 200 Error: either "to" is duplicate, or "200" is a garbage. I refreched some knowledge about routing in Linux and I don't think the "dev " (notice the extra space) should be there. If I edit /etc/wireguard/wg0.conf and remove "dev " the tunnel can stay started and there is no error in wg-quick.log PostUp=ip -4 route add 192.168.100.0/24 via 192.168.100.1 table 200 This solution works and are stable for starting/stopping the tunnel. If I however add a peer or update a peer, the config is overwritten with the "dev " in the line and it needs to be edited again. I have only tested this for "remote access to server" and have not changed anything from default values. Why do I have this problem? I saw the upgrade note that you should refresh Wireguard tunnels to get it to work. So there is an issue with Wireguard, but somehow my system/setup is different. I'll guess this is a workarond for now and maybe someone else can give a +1 if they had the same?

Still have this problem and made some more tests. Tried deleting peers and set up new, but have the same problems so I deleted all tunnels and started anew. I can start this tunnel which add these lines to wg-quick.log wg-quick down wg0 wg-quick: `/etc/wireguard/wg0.conf' does not exist But it does exist. Looks like this: [Interface] #test05 PrivateKey=ANoWVzWStD+5FBt3OoeOv4UDhDEayUDwd6n43ZmLr0M= Address=10.253.0.1 ListenPort=51820 PostUp=logger -t wireguard 'Tunnel WireGuard-wg0 started' PostUp=iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o eth0 -j MASQUERADE PostDown=logger -t wireguard 'Tunnel WireGuard-wg0 stopped' PostDown=iptables -t nat -D POSTROUTING -s 10.253.0.0/24 -o eth0 -j MASQUERADE And I can start it, which add these lines to wg-quick.log wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.253.0.1 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] logger -t wireguard 'Tunnel WireGuard-wg0 started' [#] iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o eth0 -j MASQUERADE Ok, so a tunnel seems to be up, but when I add a peer it goes wrong and the tunnel goes from ACTIVE to INACTIVE I see this added in the wg-quick.log wg-quick down wg0 [#] ip link delete dev wg0 [#] logger -t wireguard 'Tunnel WireGuard-wg0 stopped' [#] iptables -t nat -D POSTROUTING -s 10.253.0.0/24 -o eth0 -j MASQUERADE wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.253.0.1 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] ip -4 route add 10.253.0.2/32 dev wg0 [#] logger -t wireguard 'Tunnel WireGuard-wg0 started' [#] iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o eth0 -j MASQUERADE [#] ip -4 route flush table 200 [#] ip -4 route add default via 10.253.0.1 dev wg0 table 200 [#] ip -4 route add 192.168.100.0/24 via 192.168.100.1 dev table 200 Error: either "to" is duplicate, or "200" is a garbage. [#] ip link delete dev wg0 What is the table 200 problem here? Is there a wg0 missing in the second route add? Seems to be double space there? Any pointers would be apriciated - hanging on by a thread here with the server in questions far away in a different country. Also posting my diagnostics diagnostics-20221013-1053.zip