Xaero

The octopi instance is running on a raspberry pi and is reachable on my network as "octopi.local" I'm wanting to allow remote access to it through nginx proxy manager as well as the other services on my network that aren't all on my server. I ended up switching to HOST networking, moving the unraid WebUI to Port 5000/5001 and then pointing my router to my unraid's hostname. After switching to host network mode hostname resolution works properly, and I have now set it up so that I can access all of my services. I also added an entry for my local unraid hostname and ip address to redirect to the unraid WebUI so I can use those like I always have transparently.

Trying to switch to this docker from the unofficial one after many moons. I'm not changing any of the default options as such it is running on the custom (br0) network and has an ip on my local subnet. I am able to access the WebUI and set up a couple of test domains. Both of these error with 502. Looking at the access log: 2022/08/10 19:41:24 [error] 810#810: *104 octopi.local could not be resolved (3: Host not found), I can't resolve any address in my local network, trying to curl octopi.local results in could not resolve host: octopi.local. Using curl on the IP works fine. Additionally, I receive no route to host when trying to refer to the unraid server, so I can't see/forward to any dockers hosted on that server. Not sure how best to approach this. (For example, I have a service running at 192.168.1.72:8443, I get "no route to host" for 192.168.1.72 - which is my unraid box)

So I've been having an issue since installing a new SAS HBA (9305-24i in IT mode) one of the ports is flakey and two disks connected to that port will have UDMA CRC errors tick up (1st and 4th disks on the breakout). I confirmed it wasn't the cable by replacing with a new cable. I confirmed its not the disks by swapping that entire branch with another. The issue follows the port on the HBA. This has left me in a "precarious" situation where one of my parity disks is disabled and one data disk is disabled. The issue was initially resolved after swapping the ports on the HBA so I chocked it up to "Maybe it was just a loose seat" and now I'm nowhere near the server to do any maintenance, and there's nobody else who can do it for me. I plan on powering off the server until a new HBA arrives to replace this one - but until I am able to migrate some services around I can't really do that. Since I have dual-parity, the array is still emulated, but if I lose any one disk I'm kind of SOL on recovery, correct? So far this is the only indicated hardware issue I have.

Anybody able to get the GPU to idle properly with this docker? As long as steam is running the lowest power state it will enter is P0 instead of dropping to P8 (2d clocks). This is a pretty substantial power draw difference when the docker isn't actually doing anything - 20W in P0 vs 7W in P8 on my system. I had the debian steam nvidia docker before and was running it without this issue. For now I'm just closing steam within the docker and then manually opening it up again when I want to use it, but thats kind of a PITA and requires manual intervention constantly.

Would it be possible to add Core Keeper dedicated server? AppID 1963720 I've been playing with it a little and have almost got it starting. They do some unconventional stuff with their launch.sh script (launch.sh calls gnome-terminal with $PWD/_launch.sh - gnome-terminal isn't present for obvious reasons so that bombs out) I'll keep plugging at it and see if I can get it rolling on my own. Thanks for the existing dockers!

Trying to move to this from the debian buster-nvidia docker and I can't seem to get the VNC port(s) to change. I'm adding: ` -e PORT_VNC="5904" -e PORT_AUDIO_STREAM="5905"` EDIT: I realized that at some point my GUI mode started running on the nvidia card instead of the integrated GPU for my board. This was undesirable and I corrected it (my board has IPMI and the integrated graphics must be used for IPMI to be able to capture the screen). After correcting that and purging this container and setting it back up everything worked as expected. Not sure why it didn't work with the GUI running on the GPU, or why it also didn't work with DISPLAY=":0" No worried as its working as intended now.

Not sure how to best approach the situation, but the JRE recently introduced a change that breaks compatibility with older Forge modpacks. sun.security.util.ManifestEntryVerifier was changed in a way that breaks startup. The container just updated and now I cannot start my modpacks so I'll have to downgrade for now I suppose. See here: https://github.com/McModLauncher/modlauncher/issues/91 Note that only packs older than the forge version that fixes this would be affected, but still a problem.

The stream froze because ffmpeg is getting killed as a high memory consumer when the OOM procedure runs: Jan 30 01:12:57 Alexandria kernel: Lidarr invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 ... ... Jan 30 01:12:57 Alexandria kernel: Tasks state (memory values in pages): Jan 30 01:12:57 Alexandria kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Jan 30 01:12:57 Alexandria kernel: [ 19532] 0 19532 1466611 1447233 11796480 0 0 ffmpeg ... ... Jan 30 01:12:57 Alexandria kernel: Out of memory: Killed process 19532 (ffmpeg) total-vm:5866444kB, anon-rss:5789584kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:11520kB oom_score_adj:0 Jan 30 01:12:58 Alexandria kernel: oom_reaper: reaped process 19532 (ffmpeg), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB That just tells us what got killed as a result of the oom state, not what was consuming the most memory. The biggest memory consumer at the time ffmpeg was killed was this java process: Jan 30 01:12:57 Alexandria kernel: Tasks state (memory values in pages): Jan 30 01:12:57 Alexandria kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Jan 30 01:12:57 Alexandria kernel: [ 21823] 99 21823 3000629 145993 2207744 0 0 java But this table only keeps track of running processes, not files stored in tmpfs, for example. From what I can see, tmpfs doesn't appear to be using that much memory.

How much data are you piping through BORG? I see above it's configured to use /.cache/borg as its cache directory. "/" is in memory on Unraid, so it's going to cache everything in memory while it does its work. If you have individual files larger than your remaining memory this is likely to be the cause. As far as the high CPU utilization - that's more or less expected with BORG. It's going to calculate compressed, hashed backups of files and make sure they aren't duplicates of one another using the hashes before it does the compression. Calculating hashes is computationally complex, so it takes CPU power. Compression is also computationally complex and also takes CPU power. That's expected. As far as the BAR messages in the log - that's not related. Seems like the nvidia driver is asking the kernel to reserve more memory than the bus uses - which isn't completely outside of reason, but also isn't how things *should* be written according to the Linux kernel; its mostly an informational/debugging message.

You have a few options, you can burn the image to a physical disk and then boot it on real hardware - YMMV depending on OS (linux usually doesn't care) on what does/doesn't work hardware or software wise on real bare metal. For example Windows may deactivate itself if the physical configuration is too different from the VM it was running on. The other option is to use a HyperVisor or VM solution to boot the virtual hard disk file. You can import machine into VirtualBox, VMWare, set up Qemu/KVM on your bare metal OS and boot the image there etc. I would recommend snapshotting before migrating both directions (a backup before you go on a trip, and a backup before you replace the VM image afterwards. Another option is to set up Apache Guacamole or a similar remote access application and just remote into the server/vm and do your work remotely just as if you were at home working on the VM. Of course, this is restricted by your internet speed and access abroad, so might not be applicable.

Going to go ahead and open a bug report on this since I'm getting zero traction here.

Actually, that isn't feasible for me. I don't want to be stuck with an appliance that is perpetually out of date, and I also don't really have the bandwidth in my life to constantly build my own boot images for a single script, that was part of my reason for going with Unraid - to not have to constantly maintain a full set of config files and startup scripts every time something happens.

I suppose I will just roll back indefinitely or maintain my own copy of this particular initscript.

Correct. The Qemu/KVM Hypervisor is just a process running under the Linux kernel, so the Linux kernel's I/O, memory, and CPU scheduler handle dishing out resources to it. Setting things like the number of cores only result in the guest OS behaving like it has those resources available to it. When the guest OS creates a thread, the linux kernel ultimately decides which CPU core it actually runs on. An exception to this would be to pin the core assignments (this forces the kernel to always run those threads on the specified CPU) and to isolate the cores from the kernel itself (this prevents the kernel from running native Linux processes on the specified core) by combining CPU pinning and isolation you can effectively section off your CPU so that ONLY threads spawned by the guest OS are running on those CPU cores.

EDIT2: Just leave the core count untouched. As long as you aren't isolating those CPU cores from Unraid, Linux should be able to use the cores even though there is a VM running on them (since the VM is idle). Changing memory should not trip the WGA activation message.

So, I have a use case for the BIND_MGT option. I want the Unraid WebUI to only be available on my local LAN. Users connecting via WireGuard using the hostname of my server instead receive Heimdall running on a docker. I have a second management WireGuard that provides LAN access so I can access the WebUI when connected via that WireGuard tunnel, or I have Apache Guacamole for remote administration. I had this working fine, I edited /boot/config/ident.cfg to have BIND_MGT="yes" and restarted NGINX and was able to run Heimdall with manual port assignments for the correct subnets. When connecting on my lan I got the unraid dashboard, and when connecting thru wireguard I got Heimdall. Everything was peachy. I have since updated to 6.10, and the heimdall docker can no longer start because port 80 is already in use by the WebUI. I double checked I had everything set correctly, and I do. But looking at /etc/rc.d/rc.nginx, all references to BIND_MGT have been removed, indicating that I can no longer tell the Unraid WebUI to only listen on a specific interface. Is this an intended change? Am I going to have to start maintaining an override of this file and manually start the WebUI via script to maintain my intended functionality? I don't recall seeing this in the changelogs, but I could easily have overlooked it.

Keep in mind that they may all very well pass in those first two slots. The slot in question may be where the error occurs - but that doesn't always mean the slot itself is bad. The memory controller isn't on the Northbridge anymore, it's on the CPU itself. Because the LGA2011 (and it's child variants, both narrow and wide ILM) is such a large socket, it's really really easy to get not enough mounting pressure on the first go around and miss just a couple of pins or have just slightly too high of resistance on a couple of pins and lose a memory channel/slot. If you find out just one slot has the problem, pop that CPU out, clean it and put it back in. With any luck the problem will just be gone.

Both of them are on the same channel/slot. Either there is something wrong with that DIMM Module, the board, the slot or the CPU. Because this is an LGA2011 socket; I would **HIGHLY** recommend swapping a known good memory module into that slot. Retest with the memory swapped. If the issue follows the DIMM, you've got a bad stick of ram. If the issue stays with the slot, I would the pull CPU associated with that memory slot (look in the manual for the motherboard to figure out what slot 4 is attached to), clean the CPU contacts **NOT THE SOCKET CONTACTS** with isopropyl alcohol and put it all back together. It's extremely common to get a false seat on the CPU on the LGA2011 socket resulting in issues just like this one.

I think the glaring issue is that this thread seems to imply that the unraid user interface, or server itself should be hardened against external attacks. This would mean that unraid itself is exposed to the external network/internet, which basically just shouldn't be the case. This is a big clear red "don't do that." Instead, use a reverse proxy to get services running on the unraid server exposed to the outside world. As far as getting access to unraid itself exposed to the outside world, if you absolutely must, I would use something like Apache Guacamole with 2FA. This way the server itself is never exposed to the outside world, and your interface to it is protected with 2FA. I don't think this is something in the scope of unraid to develop a secure remote access implementation. I don't think the WebUI has been scrutinized with penetration testing, and I don't think a system with only a root account should ever be exposed to the internet directly.

Is this a bug?

IMHO instead of using a PCI-E 1x slot for a 10GbE adapter in any situation, you should select either an NVME to PCI-E x4 adapter, if you board has NVME slots, or a USB 3.0/3.1 10GbE adapter as it will result in higher usable bandwidth in almost every case. If thunderbolt is available, it is also a great choice. USB 3.0 is 4.8 GBit, or ~5x as fast as a PCI-e 3.0 x1 link. USB 3.1 is 10 GBit, and has very low protocol overhead so you can expect near 10GBit performance. Thunderbolt 3 is 40GBit and will obviously support full speeds for up to 3 10GBit ports, and near full speed for 4. Just my 2c. I only use my 1x slot for powering a port expander.

Even if it is, enhancements to the functionality and security of core features (disabled by default or not) should be welcome. Thanks for taking the time to improve Unraid. Maybe someday I will be able to submit some PRs

No worries - You could try this workaround that is reported to fix many issues with that chipset -- but YMMV as none of them mention this gigabit negotiation issue: https://wiki.archlinux.org/title/Network_configuration/Ethernet#Broadcom_BCM57780 If it works, you can also make that change permanent until such time that a Kernel mainline fix arrives.

Oh, that would definitely indicate that the switch itself is fine. It looks like something changed between Linux Kernel 4.14 and 4.15 that probably caused an issue with all chips in the TG3 driver: https://askubuntu.com/questions/1163256/broadcom-bcm5764m-gigabit-ethernet-wont-connect-at-gigabit-speed That chip is indeed covered by the TG3 driver: https://linux-hardware.org/index.php?id=pci:14e4-16b1-17aa-3975 And that would line up with your experience of "Works in Windows, but not here."