Avsynthe

I haven't seen anyone else mention the potential of moving to Valkey, which is just a continued open source fork of Redis now that its licensing is different. What's stopping us? I'm pretty sure it's a drop-in replacement and all our current containers that need redis should just be able to use it.

Woke up to a permissions bug with redis:latest in this template today. This fixed it for me. Note the change if you need to undo it later. Set: Extra Parameters: --user 0:0 --entrypoint /bin/bash Set Post Arguments to: -lc "/opt/bitnami/scripts/redis/setup.sh && chmod 644 /opt/bitnami/redis/etc/redis.conf && exec /opt/bitnami/scripts/redis/run.sh"

Anyone suddenly getting errors when trying to update any and all stacks? All stacks have been on my system for years and have updated fine in the past. Here is the compose file for reference: services: gluetun: image: qmcgaw/gluetun:latest container_name: gluetun-update cap_add: - NET_ADMIN volumes: - /mnt/cache/appdata/gluetun:/gluetun command: update -enduser -providers airvpn

From that github thread it looks like it was fixed, though I'm unsure if the fix has been fully released as last week I started to receive a crash loop as well but a different error: context deadline exceeded 2024-06-13T19:11:55+10:00 INFO [firewall] setting allowed input port 59339 through interface wg0... 2024-06-13T19:11:55+10:00 INFO [firewall] setting allowed input port 61710 through interface wg0... 2024-06-13T19:11:57+10:00 ERROR [ip getter] Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers) - retrying in 40s 2024-06-13T19:11:58+10:00 INFO [http server] 400 GET wrote 41B to 192.168.0.117:59634 in 7.599µs 2024-06-13T19:11:59+10:00 INFO [http server] 400 HEAD wrote 42B to 192.168.0.117:59641 in 17.235µs 2024-06-13T19:11:59+10:00 INFO [http server] 400 GET /favicon.ico wrote 41B to 192.168.0.117:59634 in 3.282µs 2024-06-13T19:12:26+10:00 INFO [healthcheck] program has been unhealthy for 31s: restarting VPN 2024-06-13T19:12:26+10:00 INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2024-06-13T19:12:26+10:00 INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION 2024-06-13T19:12:26+10:00 INFO [vpn] stopping 2024-06-13T19:12:26+10:00 INFO [firewall] removing allowed port 59339... 2024-06-13T19:12:26+10:00 INFO [firewall] removing allowed port 61710... 2024-06-13T19:12:26+10:00 INFO [vpn] starting 2024-06-13T19:12:26+10:00 INFO [firewall] allowing VPN connection... 2024-06-13T19:12:26+10:00 INFO [wireguard] Connecting to 146.70.200.194:51820 2024-06-13T19:12:26+10:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.

Hey all. I have a two containers that use an Unassigned Device SSD for their appdata as they're massive. Some have other external volumes mapped also such as the docker socket, media folders and /tmp/. To back up their appdata, I could set "save external volumes" to yes and add the other external volumes to the exclusion list? Just want to make sure this works and I don't wake up after the next backup to find it's backup massive amounts of files I've tried to exclude and nuked my array space. I also don't want to know what would happen if it tries backing up the docker socket path. I ask mainly as paths like that and /tmp/ aren't normally accessible in the provided directory list.

From what I was told on the discord, this will never be possible on this image as there is neither Nvidia nor AMD GPU drivers in existence for muslc on Alpine. I'm just about to take a dive and see if I can successfully migrate everything to the official container without having to re-setup anything as I've done a lot of work. Any help on this would be awesome.

Hey all, I'm planning on installing a large SATA SSD as an unassigned device for gaming on the Headless-Steam container. I'm looking for advice on what the current best way is of backing up the entirety of an unassigned device to a share on the array? Cheers.

Hi all, I speak for many of us when I say we don't all have the resources for multiple GPU setups split between gaming VMs and containers. Many of us have turned to solutions like steam-headless (Debian based), steamOS and other native Linux containers to get the job done while retaining GPU use for other needs. These containers have fantastic support for Sunshine/Moonlight or Steam Link game streaming for remote play, which all provide some level of remote/virtual gamepad drivers, however unlike a Windows VM, they sadly lack the main key feature when playing locally: Local Gamepad Support. xone is a Linux kernel driver for Xbox One and Xbox Series X|S accessories that serves as a modern replacement for xpad, aiming to be compatible with Microsoft's Game Input Protocol (GIP). Essentially, xone would give kernel support for the following when passed through to a container: The Xbox Wireless Adapter All Wireless Acessories All Wired Accessories All Accessories via Bluetooth (xpadneo) There is full support for: Input and force feedback (rumble) Battery reporting (UPower integration) LED control (using /sys/class/leds) Audio capture/playback (through ALSA) Power management (suspend/resume and remote/wireless wakeup) This would further open up unRAID's use cases in the gaming world and bring the same gaming VM goals far closer to a greater variety of rigs, budgets, and mixed-use setups. It also has other applications beyond gaming such as better control of home media apps with the chatpad attachment etc where supported. Repos can be found here: https://github.com/medusalix/xone https://github.com/atar-axis/xpadneo Thank you and I appreciate your consideration.

After some further digging around the time of posting this, I found a thread on the AUTOMATIC1111 github where it seems to be a somewhat common occurrence for some but isn't meant to be normal apparently. It also doesn't look like they know 100% what's causing it. https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/2180 Surely it's meant to release ram after each generation right? Regardless, with the restart unless stopped flag, it's more of just a delay once in a while after a number of generations. Small little workaround. Thanks for the reply!

Hey all, I'm having an issue where stable diffusion never releases RAM on AUTOMATIC1111. The more I generate, the higher it goes. The server went down today and I couldn't figure out why the last snapshot of the system showed 99% memory used of 64GB. I realised SD is just compounding away. This happens no matter what model I use with VAE models increasing it quicker for obvious reasons. Switching models makes no difference, it just continues on. I've had to limit SD to 20GB RAM and so it'll eventually crash when it hits. Is anyone else experiencing this?

Thanks for this! So Linux seems super straight forward. Is it a similar auto generated command line process for Mac being FreeBSD based?

Hi there guys, I can’t for the life of me find any info on the process of restoring images to Mac or Linux machines. I understand Windows gets a bootable USB, but how does this work for the other platforms? I run a real estate office predominantly using Windows machines but it’s not uncommon for agents to prefer to use Macs or already have their own. Also, how would one use the image backups to restore without a network connection if needed? This is a great piece of software but its biggest downside is that the documentation is severely lacking and heavily outdated in sections. Urbackup really need to get on that. It took me days to get LDAP working and to learn how to properly get a reverse proxy + web socket without any port forwarding working for internet client backups, and not just the webui, or to even learn it supported web sockets 😅

Please excuse the double post. I've run into an actual issue with Sunshine that is replicable on fresh installs. Not sure if this is since the most recent image update a day or two ago. I should note this is all on LAN with the container running on the Host network. I noticed an issue when trying to start a stream from a Moonlight client where an error is thrown citing port forwarding instructions. Upon checking the container, I noticed the Sunshine icon is missing from the system tray in the top right, albeit the tile is still there and can be interacted with, it's just blank. Right clicking the tile and selecting Quit results in the tile reappearing after a second or so and not properly exiting, and "Open Sunshine" does nothing. I had to open the UI via Applications > Multimedia. I played with it for a bit and thought I'd start with a fresh container and image. I noticed the tile acting in the exact same way on the fresh install, only this time there is no application entry for Sunshine to be seen. When accessing the web UI, the logs read this when attempting to start a stream from a client: [2023:08:31:20:36:03]: Info: Found encoder nvenc: [h264_nvenc, hevc_nvenc] [2023:08:31:20:36:03]: Info: Executing Do Cmd: [/usr/bin/xfce4-minimise-all-windows] [2023:08:31:20:36:04]: Info: Executing [Desktop] [2023:08:31:20:36:04]: Fatal: Couldn't bind Audio server to port [48000]: Address already in use [2023:08:31:20:36:04]: Error: Failed to start a streaming session When stopping the failed stream from the client, the logs read: [2023:08:31:20:36:24]: Info: Executing Undo Cmd: [/usr/bin/sunshine-stop] [2023:08:31:20:36:24]: Warning: Return code [1] Subsequent attempts throw a different port in the error: [2023:08:31:20:36:35]: Info: Found encoder nvenc: [h264_nvenc, hevc_nvenc] [2023:08:31:20:36:35]: Info: Executing Do Cmd: [/usr/bin/xfce4-minimise-all-windows] [2023:08:31:20:36:36]: Info: Executing [Desktop] [2023:08:31:20:36:36]: Error: Couldn't bind Control server to port [47999], likely another process already bound to the port [2023:08:31:20:36:36]: Error: Failed to start a streaming session When the container starts up and when I click Quit on the blank tray icon where it reappears, the container logs read (not sure if relevant): 2023-08-31 20:58:52,277 INFO exited: sunshine (exit status 0; expected) 2023-08-31 20:58:52,278 INFO reaped unknown pid 3294 (exit status 1) 2023-08-31 20:58:53,282 INFO spawned: 'sunshine' with pid 4190 2023-08-31 20:58:53,282 INFO reaped unknown pid 749 (exit status 0) 2023-08-31 20:58:55,017 INFO success: sunshine entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2023-08-31 20:59:17,387 INFO reaped unknown pid 3723 (exit status 0) And Sunshine logs on startup read (not sure if this is just because VNC audio is disabled or something else): [2023:08:31:21:05:45]: Error: Failed to map UDP 48000: 729 I noticed the dashboard now says the Sunshine version is Version 0.20.0 where as before it was a Dirty version. Not sure if that's relevant or if there is somehow a conflict between two fighting Sunshine instances. On one of the fresh installs, I tried installing Sunshine from the Software app over the current one, but the issue was the same. Is anyone else having issues?

Got this to work in the end! Edited my last post with the issue I was having. I posted here initially as Tailscale wasn't giving me great performance. Got it working through good old DDNS.

Thanks for your response. Under Applications > Games I have Steam and nothing else. This is where the confusion is for me, there's nothing else there. Was this removed? Searching the application finder also yielded nothing, it doesn't seem to be installed. EDIT: Just learned that this was removed and is installable now through the Software program instead. Regarding Moonlight/Sunshine, my question was is there a way to connect to Sunshine via Moonlight over the Internet remotely and away from the home network? I have a dynamic external IP so I'm looking for a good solution without having to check the IP of the house every time I want to connect when I'm away. EDIT 2: Got this to work using Cloudflare DDNS and an unproxied CNAME. This is what I was trying the whole time but the issue was the Moonlight client didn't like the "https://" before the hostname.