Fribb
-
Posts
13 -
Joined
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Fribb
-
-
11 minutes ago, wgstarks said:
When I switched to wireguard last night I used the process described in the FAQ-
https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
Scroll down to Q21.
yeah, this isn't any different to what I did. Wireguard and the VPN work fine, the curled IP from ifconfig.co/ip is different to the one I get in just my regular browser. However, the WebUI of Qbit is not accessible for whatever reason
the only errors in the linked log file are Standard error outputs from the Start Script which don't look like errors to me.
-
2 minutes ago, wgstarks said:
Where are you getting this from? I don’t see that in the FAQ at all.
In the Readme in the WireGuard Section
QuoteWireGuard
If you wish to use WireGuard (defined via 'VPN_CLIENT' env var value ) then due to the enhanced security and kernel integration WireGuard will require the container to be defined with privileged permissions and sysctl support, so please ensure you change the following docker options:-
from
--cap-add=NET_ADMIN \
to
--sysctl="net.ipv4.conf.all.src_valid_mark=1" \
--privileged=true \
-
With the PIA/OPENVPN issue, I wanted to try out Wireguard but just following the README didn't work. Setting VPN_CLIENT to wireguard, running the container in privileged mode and setting sysctl="net.ipv4.conf.all.src_valid_mark=1" will result in the container being started but the WebUI runs into a timeout.
Here are the startup parameters
2024-05-03 12:46:15.308638 [info] Host is running unRAID 2024-05-03 12:46:15.330047 [info] System information Linux 90a76e02267e 6.1.64-Unraid #1 SMP PREEMPT_DYNAMIC Wed Nov 29 12:48:16 PST 2023 x86_64 GNU/Linux 2024-05-03 12:46:15.354886 [info] PUID defined as '99' 2024-05-03 12:46:15.432609 [info] PGID defined as '100' 2024-05-03 12:46:15.531275 [info] UMASK defined as '000' 2024-05-03 12:46:15.553667 [info] Permissions already set for '/config' 2024-05-03 12:46:15.578096 [info] Deleting files in /tmp (non recursive)... 2024-05-03 12:46:15.609182 [info] VPN_ENABLED defined as 'yes' 2024-05-03 12:46:15.633233 [info] VPN_CLIENT defined as 'wireguard' 2024-05-03 12:46:15.656610 [info] VPN_PROV defined as 'pia' 2024-05-03 12:46:15.687296 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf 2024-05-03 12:46:15.718762 [info] VPN_REMOTE_SERVER defined as 'nl-amsterdam.privacy.network' 2024-05-03 12:46:15.744488 [info] VPN_REMOTE_PORT defined as '1337' 2024-05-03 12:46:15.765793 [info] VPN_DEVICE_TYPE defined as 'wg0' 2024-05-03 12:46:15.787013 [info] VPN_REMOTE_PROTOCOL defined as 'udp' 2024-05-03 12:46:46.159324 [info] LAN_NETWORK defined as '192.168.1.0/24' 2024-05-03 12:46:46.187446 [info] LAN_NETWORK exported as '192.168.1.0/24' 2024-05-03 12:46:46.210320 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1' 2024-05-03 12:46:46.233490 [info] VPN_USER defined as 'redacted' 2024-05-03 12:46:46.256255 [info] VPN_PASS defined as 'redacted' 2024-05-03 12:46:46.279149 [info] STRICT_PORT_FORWARD defined as 'yes' 2024-05-03 12:46:46.302224 [info] ENABLE_PRIVOXY defined as 'yes' 2024-05-03 12:46:46.327174 [info] VPN_INPUT_PORTS not defined (via -e VPN_INPUT_PORTS), skipping allow for custom incoming ports 2024-05-03 12:46:46.350626 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports 2024-05-03 12:46:46.373783 [info] ENABLE_STARTUP_SCRIPTS not defined (via -e ENABLE_STARTUP_SCRIPTS), defaulting to 'no' 2024-05-03 12:46:46.396916 [info] WEBUI_PORT defined as '8085' 2024-05-03 12:46:46.435452 [info] Starting Supervisor...When I run the same configuration with just OpenVPN instead of wireguard, as soon as I get the
2024-05-03 12:57:58,270 DEBG 'watchdog-script' stdout output: [info] qBittorrent process listening on port 8085log output, I can access the WebUI. When I change VPN_CLIENT to wireguard, the same log output happens but the WebUI is running in the timeout.
full log output with redacted possibly private information https://pastebin.com/avNzwj9g
-
2 hours ago, Rysz said:
"UPS Settings" has nothing to do with NUT, it's a separate tool (apcupsd).
In fact you should set "Start APC UPS daemon:" to "No" under "UPS Settings".
NUT and apcupsd cannot run at the same time - they'll interfere with each other.
Data stale warnings are usually USB timeouts and nothing to worry about.
Broken pipe warnings always occur when killing the NUT service, that's normal too.
So as long as everything works, "Start APC UPS daemon:" to "No" and you're all good.
Interesting, I disabled the UPS Settings and NUT seems to show everything again. Though I am wondering why it worked for a year and just now wants to crap the bed...
Thanks for the easy fix.
-
This morning I got the message "Warning communication lost with UPS".
I checked my NUT Settings and the UPS is listed as "On Line" with battery charge and NUT Details. But in the UPS settings it states "Lost communication". I already restarted both services and also switched USB ports without any change.
I do see a few warnings in the syslog like "Poll UPS failed - Data stale" or when I restart the NUT service I get "WARNING: send_to_all: write 34 bytes to socket 16 failed (ret=-1), disconnecting: Broken pipe"
diagnostics are attached.
I have the CyberPower CP1500EPFCLCD for a year now which was running without any issues.
-
I would like to make a suggestion. While I like the "container by container" approach of doing the backups to reduce the time a container isn't available, in some instances this could also be a problem. For example, stopping the database of a service will potentially break the service accessing that database.
A more specific example, I have a Tautulli container which can monitor the Plex logs which are acessible through a volume mapping to the Plex container config. However, currently the Backup of Tautulli fails because the Plex Logs are changing. I had to now remove that feature and the volume mapping for Tautulli getting backed up correctly.
I also see that a ToDo is to "Use Dockerman default order when no order was set before" which is good but doesn't necessarily fix the issue I highlighted above.
What I would like to see is that you can "group" Containers so that they are stopped as a whole and then started after they are backed up. So, for example, Plex and Tautulli are in such a group and both are getting stopped, Tautulli is backed-up and started, then Plex is backed-up and started.
-
1
-
-
13 hours ago, ich777 said:
That's a think I can't answer...
Are you really really sure that you've booted into UEFI before? I think if you upgraded to 6.9.0rc2 UEFI was the default boot mode because a old SandyBridge machine gave me problems when I've upgraded to 6.9.0rc2 before (UEFI boot was deactivated in the BIOS entirely and Unraid won't boot any longer, after I rebooted to finish the upgrade process).
Yes, I'm really really sure that I booted into UEFI before. I think I even read somewhere that you should use UEFI because that is the new standard?!
I had it on the old board, running 6.8.3 and the new board running 6.8.3 and 6.9-rc2 but on 6.8.3 I had the "old" Nvidia approach which I can't reproduce anymore because of missing drivers etc or I would have tried to see if that is a problem there too and my GPU has some issues. While testing the new components for my DAS I had the old board and even plugged the GPU into it and ran some transcodes without that problem turning up. Whatever the case, running in legacy seems to have fixed that for whatever reason.
-
1
-
-
4 minutes ago, ich777 said:
Are you sure that you booted with the old Motherboard and 6.8.3 also to UEFI?
Can you try to boot into Legacy without the GUI, start a transcode and then see if it actually stays at the fan speed?
Also when you are at it, you can try to enable perstistence mode from the beginning. Legacy solves so much problems with Linux and Nvidia.
I see this also on my main machine with Debian and the official Nvidia drivers, updating the drivers in UEFI is a real pain...
I'm pretty sure, yes.
So, the transcodes are through, no GUI mode, persistance mode 1 and loaded with Legacy. Seems to run as it should but I will keep and eye/ear on it but hopefully it will stay that way. Still, why did it work before and not now anymore?
-
2 hours ago, ich777 said:
The driver version didn't change in any way...
The persistence mode doesn't work with all cards and Nvidia also stated that this will be no longer supported and will be deprecated in the near future.
Try to boot with Legacy please, eventually this will solve the issue.
This has actually to do with the BIOS of the card itself an how the manufacturer implemented the "idle" mode or the reset of the card. I think something is resetting the card after some time so that the fans spin at 100% up to if something uses the card or load is on the card then the default fan curve kicks in.
If you have a X server (GUI) running some load is on the GPU and the BIOS should tell the card to go into the default fan curve.
Hope this explains this a bit.
So, I booted in legacy mode and with GUI and let some ffmpeg transcodes running, GPU went up to 62°C and stayed there while the fan was at 40%. So far, hopefully I don't jinx it with saying that, the GPU has stayed quiet and at 35% fan speed.
What is weird to me is that I didn't had this behaviour the last year and only recently after upgrading to 6.9 (and switching Motherboards), I already have the latest bios on the MB.
-
1
-
-
1 minute ago, ich777 said:
What do you mean exactly with this? What previous version?
Is this a new card that you've installed in the server or have you got it running also on previous versions?
This seems like a idle problem with the card itself that is mainly dedicated to the BIOS of the card and not the driver itself.
You can try to boot into GUI mode with the card and see if this helps.
Are you booting with UEFI or Legacy, try to boot with Legacy if you are booting with UEFI mode since this solves most problems on most Linux machines with Nvidia cards.
You can also try to enable persistance mode with the command: 'nvidia-smi -pm 1' but this command will be soon be deprecated by Nvidia.
I meant a previous driver version because I didn't had this issue a couple of weeks ago. I don't know when the v455.45.01 so this might just me grasping at straws.
This is a GPU I use/used for a year now in the same server and only recently when I did my DAS server expansion and upgrade to 6.9 had this problem. I did try it with a different board while testing the DAS hardware and the problem didn't turn up there for some reason (also Unraid 6.9 and v455.45.01). I did run it with GUI mode for a while and it seemed to not happen there but I did not extensively test it as I did today running a few ffmpeg transcodes.
I boot with UEFI mode.
I already had the persistance mode active and also disabled and enabled it a couple of times trying to figure this out, without any luck.
Now that I stopped the array it suddenly stopped and after a couple of minutes it started again. Disabled the 2 docker containers that have the GPU passed through and it dipped shortly but stayed at max fan speed.
I rebooted in GUI mode now and the Fan has settled down again, I have to do some tests first to be sure that it is "working". Though I don't know if that should be the solution...
-
I have some issue with my 1660 Super. When the GPU is is under load it will go up to 60°C and hover around 40% fan power. After a while, after the GPU has a load of 0%, the temperature is back to normal 36°C and it is in P8 power state the fan decides to spin up to 100-110% and stay there for a while. After a short or long while (currently active for 10 minutes) it will settle down again but shortly after will ramp up again.
I got the latest drive v455.45.01 installed and am wondering if there is a way to install a previous version just to rule out any issues with the driver itself.
I'm running Unraid 6.9.0-rc2, the GPU is at 8 lanes if that makes any difference. I would restart but I have a few pre-clears running which will still take a few hours.
-
I am really out of ideas here and this behaviour is driving me nuts because it doesn't make any sense but first my systems stats:
AMD Ryzen 5 3600, NVIDIA Geforce GTX 1660 Super, Unraid 6.9.0-rc2, NVIDIA Plugin with Driver Version 455.45.01
What happens is that my GPU is cranking up the Fan to 110% while there is no load, the temperature is at 30-ish °C and the GPU is even Idle. Even better is that I had some Transcoding Jobs running an hour ago at which the GPU was at ~35% Fan speed while being at 60°C. But now, half an hour later, it spins up the Fan sounding like a jet engine for no reason (or at least no reason I can find.
I have two docker container running that got the GPU passed through, Plex and Tdarr (v2) but even with both disabled the behaviour doesn't change.
One thing I couldn't check would be to install a different Nvidia driver version because both, the specific and latest, are the same version.
What I also tried was to reseat the GPU, use a different PCI-E Slot on my motherboard but that didn't change anything.
I'm out of ideas. I really hope that the GPU isn't broken...
Edit: I restarted Unraid, again, to maybe get it settle down again. Now it runs hasn't stopped so far but what I also noticed is that the Monitor I had connected to the HDMI port is completely black and also doesn't even allow me to switch channels until I disconnect the HDMI cable...
[Support] binhex - qBittorrentVPN
in Docker Containers
Posted
Thank you, that was it. I don't know why that was set to '192.168.1.0/24'. set that to my correct LAN network and now it works.