idkwatimdoin

Good question. I don't recall when I made that change but it's been like that for quite some time. If I were to change it down to 20G, would that impact the existing Docker containers I have? Or will it just rebuild? I see. May have been remnants of moving everything to array when I changed cache drives. I'll look at that later today. Where are you seeing this? The promiscuous/blocked logs? They only refer to port 2 as far as I can see. As for what is spamming port 23, I haven't the foggiest as I don't use telnet for anything, only SSH. Are you able to see any more info as to where the connection attempts are coming from?

Hi, Have started receiving warnings that my log files are nearing 100% and have been trying to work out why. If I manually look at the docker.log.1 file, it shows a repeating 'starting signal loop' from moby but not sure why it's started within the last couple of weeks or whether it's related. time="2023-01-19T01:11:08.810433865+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:11:08.810622094+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:11:08.810682107+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:11:08.811308407+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e4236caee8994d9f103782165ec3884e41400ce9094ae8aaa9917617ff313da pid=40475 runtime=io.containerd.runc.v2 time="2023-01-19T01:11:08.885314367+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:11:08.885523569+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:11:08.885564943+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:11:08.886076138+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e390fd60ea6e65820c5e4e5ab570c6c9998db4997f39e95d55e98d319bd2119 pid=40521 runtime=io.containerd.runc.v2 time="2023-01-19T01:12:11.044193548+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:12:11.044408590+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:12:11.044466804+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:12:11.044917385+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e4236caee8994d9f103782165ec3884e41400ce9094ae8aaa9917617ff313da pid=1512 runtime=io.containerd.runc.v2 time="2023-01-19T01:12:11.550734620+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:12:11.550943282+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:12:11.550986842+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:12:11.551531510+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e390fd60ea6e65820c5e4e5ab570c6c9998db4997f39e95d55e98d319bd2119 pid=1727 runtime=io.containerd.runc.v2 time="2023-01-19T01:13:13.201550504+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:13:13.201763393+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:13:13.201804197+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:13:13.202338359+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e4236caee8994d9f103782165ec3884e41400ce9094ae8aaa9917617ff313da pid=13786 runtime=io.containerd.runc.v2 time="2023-01-19T01:13:14.762442280+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:13:14.762640405+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:13:14.762679552+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:13:14.763138656+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e390fd60ea6e65820c5e4e5ab570c6c9998db4997f39e95d55e98d319bd2119 pid=14205 runtime=io.containerd.runc.v2 time="2023-01-19T01:14:15.347267221+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:14:15.347479993+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:14:15.347522144+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:14:15.348121927+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e4236caee8994d9f103782165ec3884e41400ce9094ae8aaa9917617ff313da pid=24400 runtime=io.containerd.runc.v2 time="2023-01-19T01:14:16.900834894+10:30" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1 time="2023-01-19T01:14:16.900988734+10:30" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1 time="2023-01-19T01:14:16.901031182+10:30" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1 time="2023-01-19T01:14:16.901436282+10:30" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/8e390fd60ea6e65820c5e4e5ab570c6c9998db4997f39e95d55e98d319bd2119 pid=24747 runtime=io.containerd.runc.v2 Diagnostics attached. Any help would be appreciated. Thank you. notyourunraid-diagnostics-20230119-0126.zip

Welp, managed to get the prefill container to work with the lancache-bundle container (changed DNS back to what the bundle was and it just worked? (didn't before)). Sounds like the standalone lancache containers are a bit broken (for my use case), and I do hope @Josh.5 doesn't depricate his container as it works wonders. Either way, crisis averted. Thanks for responding.

True, however without the IP it defaults to DHCP, which was a lot lower in the IP range I have available, so kept them together. Yes, I did: Based on Spaceinvader's tutorial video I linked earlier, yes it does seem to be needed. Happy to try an alternative method if you think one fits better. As for DNS, I use NextDNS (a variation of PiHole/Adguard etc - https://nextdns.io/) Australia Unfortunately for me it's quite often. Downloading direct from Steam CDNs outside of Lancache are always stable, so I find it odd for it to become unstable while using Lancache and stable outside of it. I do, yes, and what you say makes sense. Unfortunately the server I have has all HDD bays populated and the NVMe adapter in use is on a PCIe bracket in the server (as the Poweredge does not support NVMe or M.2s natively). Interestingly enough, I was using Josh5's Lancache-Bundle just fine, but the prefill container could never communicate with the bundle for whatever reason. The only reason I spun up the separate containers was because prefill did work, but then had these issues instead. In addition, the lancache-bundle is also using an array share and hasn't crushed I/O at all.

I've recently implemented the lancache-prefill container on my Unraid and it's acting rather strange. I followed Spaceinvader's setup guide to set this all up: EDIT: Should probably add what my setup is: 192.168.1.173 = lancache-prefill 192.168.1.174 = lancache-dns 192.168.1.175 = lancache Blizzard prefill will sometimes work, sometimes come up with connection refused. Steam prefill will download the games intermittently (sometimes error downloading, sometimes constant retries, sometimes nothing at all). Unfortunately I set the log files to clear inadvertently, so will paste the error once it comes up again. If I tail -f to the log file, I can see (when it works) downloads to the lancache are working as the logs are filling. Not exactly sure what the go is, but it's probably something simple I've done to break it. ie: when working: [10:39:45 AM] Retrieved product metadata 36.4256 [10:39:45 AM] Downloading 80 GiB Downloading.. ━━━━━━━━━━━━━━━━━━━━━━━━━━ 7% 00:59:16 5.9/80.0 GiB 178.9 Mbit/s [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 95796 "-" "-" "HIT" "level3.blizzard.com" "bytes=134401104-134496899" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 35948 "-" "-" "HIT" "level3.blizzard.com" "bytes=139660436-139696383" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 35312 "-" "-" "HIT" "level3.blizzard.com" "bytes=142388632-142423943" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 37416 "-" "-" "HIT" "level3.blizzard.com" "bytes=147433099-147470514" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 139587 "-" "-" "HIT" "level3.blizzard.com" "bytes=142494331-142633917" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 104460 "-" "-" "HIT" "level3.blizzard.com" "bytes=146886623-146991082" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 279348 "-" "-" "HIT" "level3.blizzard.com" "bytes=142912763-143192110" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 219811 "-" "-" "HIT" "level3.blizzard.com" "bytes=130888351-131108161" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 106040 "-" "-" "HIT" "level3.blizzard.com" "bytes=136775659-136881698" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 200330 "-" "-" "HIT" "level3.blizzard.com" "bytes=144267481-144467810" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 105703 "-" "-" "HIT" "level3.blizzard.com" "bytes=149023459-149129161" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 262034 "-" "-" "HIT" "level3.blizzard.com" "bytes=145291719-145553752" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 91984 "-" "-" "HIT" "level3.blizzard.com" "bytes=146394919-146486902" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 372961 "-" "-" "HIT" "level3.blizzard.com" "bytes=145818916-146191876" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/34/48/3448e41e21d3724195efe6ef688e81d6 HTTP/1.1" 206 3615055 "-" "-" "HIT" "level3.blizzard.com" "bytes=188148148-191763202" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 170670 "-" "-" "HIT" "level3.blizzard.com" "bytes=144842503-145013172" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 142495 "-" "-" "HIT" "level3.blizzard.com" "bytes=150512294-150654788" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/34/48/3448e41e21d3724195efe6ef688e81d6 HTTP/1.1" 206 6169748 "-" "-" "HIT" "level3.blizzard.com" "bytes=148658598-154828345" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/34/48/3448e41e21d3724195efe6ef688e81d6 HTTP/1.1" 206 1585078 "-" "-" "HIT" "level3.blizzard.com" "bytes=198792252-200377329" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 32612 "-" "-" "HIT" "level3.blizzard.com" "bytes=150116412-150149023" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 38635 "-" "-" "HIT" "level3.blizzard.com" "bytes=144575843-144614477" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 475054 "-" "-" "HIT" "level3.blizzard.com" "bytes=133722331-134197384" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:25 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 36488 "-" "-" "HIT" "level3.blizzard.com" "bytes=155993088-156029575" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 64897 "-" "-" "HIT" "level3.blizzard.com" "bytes=153538616-153603512" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 69408 "-" "-" "HIT" "level3.blizzard.com" "bytes=155814401-155883808" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 92917 "-" "-" "HIT" "level3.blizzard.com" "bytes=152477644-152570560" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 36626 "-" "-" "HIT" "level3.blizzard.com" "bytes=156169945-156206570" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 35194 "-" "-" "HIT" "level3.blizzard.com" "bytes=156355825-156391018" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 125568 "-" "-" "HIT" "level3.blizzard.com" "bytes=154258141-154383708" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 75150 "-" "-" "HIT" "level3.blizzard.com" "bytes=156243988-156319137" [blizzard] 192.168.1.173 / - - - [22/Dec/2022:10:41:26 +1030] "GET /tpr/wow/data/4f/ab/4fab5ff2d92107a8be6ef03077d10a81 HTTP/1.1" 206 69465 "-" "-" "HIT" "level3.blizzard.com" "bytes=156065003-156134467" In addition, when the prefill is running as normal, accessing SMB file shares slows to an absolute crawl (some shares take over a minute to load). When the prefill container is not running, takes less than a second. Lastly, the game clients (ie. battlenet for Blizzard) won't actually download from the cache, even though my DNS is setup to do just that. I have DNS rewrites in place (using NextDNS) to point the CDNs to my lancache, but that doesn't seem to help). The URLs rewritten are from this list: https://github.com/uklans/cache-domains/blob/master/blizzard.txt, all pointing to my lancache instance (192.168.1.175). Any help would be appreciated (sorry for the long post). EDIT2: Error log attached for failed downloads (for battlenet) battlenet_prefill.log

Machine has been restarted since the anomaly, so current diagnostics are now meaningless, and I'm not rolling back then upgrading to get them again, but appreciate the input.

Just adding my 2c/experience with the upgrade process. Went from 6.9.2 to 6.10.2, no LAN NICs on next boot. Found adapters I have in my Dell Poweredge appear to be the affected ones mentioned here (Broadcom NetXtreme II for reference, running in bond0). Ended up adding the blank tg3.conf file to the USB boot drive, LAN adapters now functional. Strange side effect however; the upgrade appeared to completely remove my NVIDIA and DVB drivers? Only realised this when trying to run the docker container for Plex and having it return 'Error: Unable to find runtime nvidia'. Is this expected behaviour? Or just an unexpected anomoly? (reinstalling the respective drivers from the CA App store has fixed the issue FWIW).

Yes using an external DB and also imported the schema. For whatever reason though, I just reinstalled it from scratch and made no changes to config, and 'it just works'. NFI why, but I'm not questioning it.

Have tried setting this up today, and can't get the web UI to load the login prompt without throwing this: There's no errors in the Apache Guacamole docker, nor MariaDB. The user and password work for the database I setup for this container, so I'm at a loss. Have tried both Unraid templates (with and without mariadb), Docker has 'host access to custom networks' enabled, and have also tried different networks (br0 to give the container it's own IP, as well as my reverse proxy network). Probably something simple, but any help would be appreciated. Thanks.

Fixed the issue; ended up being an ID10T error. The Dell drive caddies have a SAS and SATA hole layout, and I figured 'hey, I should use the SATA holes!'.... nope; the drives were not connected to the backplane as I didn't screw the drives into the correct holes in the caddy. Now using the SAS holes, and lo and behold everything works!

Hi all. I've been using Unraid for quite a while now and had the means to migrate my server from a makeshift server to a Poweredge unit I've acquired. It comes with a PERC H700 mini flashed to LSI 2308 in IT mode and had come with 4x SAS drives. Installed a test environment of Unraid, worked fine. Started migrating my hard drives into it (7x Seagate Ironwolf NAS SATA 10TB drives), turned the server on and... nothing. No SATA drives. Turned off the server, plugged the SAS drives back in, nada. The only drives being detected are my NVMe cache drives. Tried plugging in a mix of SATA and SAS drives, same outcome. I have no idea what's caused Unraid to no longer find any SAS or SATA drives. To my knowledge, this controller should support both SATA and SAS drives. Tried checking whether the BIOS or iDRAC would show the drives, but neither did (even when functioning previously) as the LSI has been flashed into IT mode. Diagnostics attached. The syslog shows the LSI SAS 2308 controller still showing up and enabled, so I'm at a loss. Any help would be appreciated. Thanks. tower-diagnostics-20220106-2316.zip

Client is 100% on Experimental (game version confirms that). I'll rebuild the container at some point and see how we go. Thanks anyways @ich777- great work as always

/facepalm... no idea why I didn't pick that up myself; forgot that the dedicated server defaults to EA(also just rechecked the patch notes and somehow missed (EXPERIMENTAL) against the latest version...). I've added -beta experimental to the game parameters and validated the files. It appeared to download an update, but the game still complains of a mismatch (server doesn't match the client). Tried -beta -experimental, same deal. I suspect I might need to rebuild the docker container completely as it still thinks EA is Experimental.

Has anyone encountered any issues with the Satisfactory container not pulling the latest game version? (even though the logs suggest the latest has been pulled). Is there a way to interact with steamcmd from within the Satisfactory docker to try and force an update? I also installed the same container on a completely different server and no difference. Satisfactory is throwing a 'game version mismatch' error: From the different server (new install): Update state (0x5) verifying install, progress: 2.67 (120586243 / 4522427563) Update state (0x5) verifying install, progress: 6.94 (314071968 / 4522427563) Update state (0x5) verifying install, progress: 10.79 (487774880 / 4522427563) Update state (0x5) verifying install, progress: 15.19 (686813465 / 4522427563) Update state (0x5) verifying install, progress: 19.87 (898567076 / 4522427563) Update state (0x5) verifying install, progress: 25.74 (1163915780 / 4522427563) Update state (0x5) verifying install, progress: 29.96 (1354779631 / 4522427563) Update state (0x5) verifying install, progress: 34.42 (1556748166 / 4522427563) Update state (0x5) verifying install, progress: 39.39 (1781451636 / 4522427563) Update state (0x5) verifying install, progress: 44.03 (1991436565 / 4522427563) Update state (0x5) verifying install, progress: 47.12 (2131001286 / 4522427563) Warning: failed to init SDL thread priority manager: SDL not found Update state (0x5) verifying install, progress: 51.67 (2336568147 / 4522427563) Update state (0x5) verifying install, progress: 55.57 (2513281039 / 4522427563) Update state (0x5) verifying install, progress: 60.30 (2726960366 / 4522427563) Update state (0x5) verifying install, progress: 65.98 (2984071282 / 4522427563) Update state (0x5) verifying install, progress: 71.34 (3226146982 / 4522427563) Update state (0x5) verifying install, progress: 76.97 (3480813547 / 4522427563) Update state (0x5) verifying install, progress: 82.25 (3719792347 / 4522427563) Update state (0x5) verifying install, progress: 88.28 (3992280189 / 4522427563) Update state (0x5) verifying install, progress: 93.53 (4229697601 / 4522427563) Update state (0x5) verifying install, progress: 98.72 (4464500652 / 4522427563) Success! App '1690800' fully installed. ---Prepare Server--- ---Server ready--- ---Start Server--- From the game: EDIT: Hmm, might be a Steam issue; loaded a new version of the dedicated server from Steam directly and it's also not up to date... but would be good if someone else can confirm so I can at least verify it's not just me.

Ahh, Game Parameters and Extra Parameters aren't the same thing (that's where I was getting confused): vs: As the error suggests, 'ultihome' is because '-m is another abbreviation for --memory in unRAID, and it's in the wrong format. Just tried again under Game Parameters only, and (after a few restarts) it seems to have registered. Thanks @DazedAndConfused.

@DazedAndConfused Are you adding the -multihome part to the Extra Parameters template under Advanced View? Or somewhere else? If I add as you've pasted above, I get: invalid argument "ultihome=0.0.0.0" for "-m, --memory" flag: invalid size: 'ultihome=0.0.0.0' If I add a double-dash ( -- ) : unknown flag: --multihome Adding to Game Parameters starts the container, but throws the error listed on the QA website:

The wiki is your friend @ra1k_0. There are suggestions for improving multiplayer under 'temporary lag solution', but I've implemented them anyway to prevent that kind of issue happening. Not sure if @ich777 wanted to consider doing the same for this template? Others that have spun up the dedicated server as a Docker container appear to have.

Right, my bad. I'm used to manually spinning up docker files in non-Unraid environments and added the Variable path to substitute for -v. As for raising it under Satisfactory Steam Community/their own QA website, they have announced plans to spin up Satisfactory Server as a docker hub container, but no ETA on when that will actually come to fruition. Not a big issue, I just like things to represent actual time zones of where I am. Thanks @ich777.

I might have missed it somewhere in the documentation, but is it possible to get the times in the logs to match your local timezone rather than UTC? I've tried adding the TZ variable: -e TZ="America/New_York" \ (example) to the container as well as: -v /etc/localtime:/etc/localtime:ro \ But the logs seem to revert back to UTC (I'm +9.5): [2021.10.30-05.42.44:871][602]LogGame: Write Backup to Disk and Cleanup time: 0.003 seconds [2021.10.30-05.42.44:874][602]LogGame: Total Save Time took 0.428 seconds [2021.10.30-05.47.44:648][574]LogGame: World Serialization (save): 0.166 seconds [2021.10.30-05.47.44:913][574]LogGame: Compression: 0.262 seconds [2021.10.30-05.47.44:913][574]LogGame: Write To Disk: 0.002 seconds [2021.10.30-05.47.44:913][574]LogGame: Write Backup to Disk and Cleanup time: 0.003 seconds EDIT: Actual Unraid Template screenshots would probably help:

True, but people have been asking for dedicated servers for quite a while now, so I figured a lot of people would be trying to set this up

Thank you for the Satisfactory template @ich777! I was literally in the midst of spinning up a dedicated server on a VM and stumbled across this. I do however seem to have some weird anomaly with trying to connect (it is likely a me problem as I can't find any reports of the same issues happening with someone else). This happens with both Windows Server (via Steam app) and Linux (via steamcmd). When I try and connect to the game server, my logs are spammed with the following (the IP is from my Steam client on my gaming PC): None of the server info loads in Game on my client (game thinks the server is offline). I understand this is all still experimental, but has anyone else had this same issue as yet? EDIT: Fixed my own issue; turns out I made an unnecessary port change (tried connecting to 7777 instead of 15777). Swapped to 15777 and now it loads.

I've had 3 DNS servers on 2 different bits of hardware fail on me in the last 24 hours (power blackouts really aren't fun), so yes I have; it's now set to a known public DNS provider and everything "just works".

Both plugins remain once booted. Here you go. syslog

I did notice an update earlier (for both nvidia and DVB). Installed both and rebooted.... The boot time is significantly faster now! I'll keep an eye on this for a few days but suffice to say it no longer takes my server 90 mins to boot!

Ah yes of course! Forgot about that handy feature. Thanks again!