Mainfrezzer
Members
-
Joined
-
Last visited
Everything posted by Mainfrezzer
-
We do know that theyre sleeping together these days but im certain an intel igpu does not use the nvidia plugin :D
-
/mnt/user is all array disks + pools. /mnt/user0/ (although depricated) is just the array disks, no pools
-
You might have to set the variable in the qBittorrent template for the incoming port Torrenting isnt my strong expertise but it should work absolutely fine from the logs as its binding properly to the wireguard interface ip (10.123.0.2 and fc00:123::2), as long as your provider does forward it to your client.
-
they share the same "interface", every port that you map to the wireguard container goes also to the qbittorent container. So if you run something on 5023/tcp, you map that to the wireguard client and it will reach the attached qbittorrent container, same with 38282/udp for example, for lan that is. Same for the vpn connection, everything that hits the wireguard ip of the container, hits qbittorrent aswell, if its listening on that port, no template modification needed
-
dont nail me down on it, should be unraid 7. Although the old header should work fine if applied to the md*p1 devices, but im not absolutely sure on that. Doesnt hurt to create a new backup just to have it Edit: should mention that this is only for array devices, the pools are still the "old way"
-
wrong devices, you backup the md*p1 devices
-
i see why, 8080 is "blocked/already used" by privoxy and the gui runs on 8080. You can change the privoxy port by changing this variable Edit: if you get the "unauthorized" message in the browser, add WebUI\HostHeaderValidation=false to the qBittorrent.conf under [Preferences]
-
Theres no such thing for sata, the nvme drive "reports" it itself
-
Which container is it, where the gui isnt working?
-
did you add the ip range of your lan/the network youre trying to access the container gui from, to the template of the wireguard container?
-
Depends what you want to do. If you want other container to go through the VPN, you just select their network to be the vpn container like this the privoxy http proxy and mircosocks socks5 proxy are more for like things hosted outside of unraid. Smarttube on a firetv stick (i dont know if libretube supports proxy) or just a seperate firefox browser that goes through there on your pc.
-
Yeah, the build in wireguard implementation doesnt support ipv6 at all atm. I still havent come around to attempt to fix it but if you need ipv6, ive a container in CA you can use for it.
-
Ive seen the post in discord just gonna ask here again what i asked over there. Are you absolutely sure that your "remote" address is actually the Panel Address? The "could not unmarshal response: invalid character '<' looking for beginning of value" is a sign that youre trying to hit something else than the panel, i.e. the Unraid WebGui or something.
-
Ich war nicht derjenige der auf Opensense umgestellt hat, ich hab immer noch die Fritzbox am laufen. Hab damals einfach 6.11.5 weiterbenutzt, bis das behoben war und hab dann wieder die bridge angeworfen
-
Ive a simpel script running that pings the peer ip and if it fails multiple time in a row just runs wg-quick down wg2 and wg-quick up wg2 rinse and repeat. Edit: I currently can't get the file from the server cause the web terminal/log is broken on mobile chrome, but it's similar to the fix I use in my docker container https://github.com/Mainfrezzer/wireguard-bridge/blob/main/additions/healthcheck.sh
-
Never heard of that behavior or setting before, where did you get that from? Ark does generally do statis and some hibernation by default, but there isnt any "no players hibernation" for the server, its all for creatures etc. Edit: The closest thing to that behavior only exists in ASE afaik and that has only to do with tickrate and was a test command
-
in docker there isnt a real "auto-rebuild", its just what the gui sells you it as, its a full recreation of the container, i.e removing and deploying it.
-
seems like the appfeed has been snoozing for the last 2 days. Gotta wait.
-
Ive been bothering the Htop people for a bit now and i still think this is an issue with htop, to a certain degree as btop works fine and older htop version works to 50%, the sensors work fine too, although it could be a package that was updated but im only 1 person with 2 intel machines. On the 2 systems ive tested it on, htop displayed the issue differently. My actual unraid server displays NA temperature readings, while my PC will display bogus temperature infos for all cores. Thats being said, within certain containers, htop is actually able to read the temperature correctly with the same version as unraid ships. The odd part is, it started being broken with kernel 6.12.40 (beta.1) also at the same time, the thor kernel 6.16 showed this behavior. Then came i think beta.2 with kernel 6.12.42, which actually fixed the issue and it worked as intended.(for thors 6.16.1, it was working again as well, last time i checked that kernel out) So that led me to think it was just an issue with the kernel itself. Then came Kernel 6.12.47(could have reappeared earlier but i wouldnt know) which absolutely broke it again and is still broken until now (6.12.53). But given that i can get proper readings from within containers, makes me believe it must be something else. 6.12.40 - Htop 3.4.1 i3-14100 6.12.40 - Htop 3.3.0 i3-14100 6.12.47 - Htop 3.4.1 i5-14600k *bogus readouts as they all just read the same sensor of coretemp 6.12.53 - Htop 3.4.1 i3-14100 6.12.53 - Htop 3.4.1 i3-14100 inside Container *the only way to get a proper and correct read out 6.12.53 - Btop 1.4.5 i3-14100 In all versions sensors hands out information correctly. Would be handy we could get more eyes on and figure out what the hell is happening. I attach the compiled version of btop btop-1.4.5-x86_64-1_Unraid.txz
-
Ist ja nicht mehr notwendig, schon lange nicht mehr, da es ein paar Kernelversionen vor dem 6.12.11 (Unraid Version) Kernel gefixt wurde. Aber so ist es nun mal mit temporären Hilfsmittel, die bleiben permanent. Glaube der einzige positive Grund der da erwähnenswert ist, fürs beibehalten, hat was mit VMs zu tun und deren Anbindung. Die hätten schon damals, als dieser "fix" kam, die Option zum deaktivieren des macvtap/vhost hinzufügen sollen. Die Option sind da zurzeit limitiert ohne groß da selbst mit den Systemdateien rumzufummeln. Ich hab mich schon damals geärgert deswegen [6.12.6] Macvtap causes consistent package loss - Stable Releases
-
Das ist deren macvtap work around für die macvlan call traces, die ja seit glaube ich 6.12.11 gefixt sind. Das man eth0 nicht mehr "nackt" benutzen kann ist echt schade. Hab deswegen briding an um das vhost interface loszuwerden
-
Did apply the rollback and it should work again now. Seemed to be very specific to postgres for some reason, although i didnt check mysql.
-
If youre willing to test something, could you change the repository from the panel from "ghcr.io/mainfrezzer/pelican-panel:latest" to "magnon.ovh/mainfrezzer/pelican-panel:latest" and see if its still borked?
-
did you update wings to the latest version (beta18) as well? also which pelican container are you using? mine or the official one? Edit: (if its the official one. You have to wait till they release an update to it, there is a fix for it https://github.com/pelican-dev/panel/pull/1787 mine has that already included, so if its still broken, would be worth knowing)
-
sounds like the initial check didnt detect any ipv6 address and used the ipv4 only config. You can edit the unbound.conf in the appdata location and uncomment the ipv6 specific lines #interface: ::1 #do-ip6: yes
