PatrickK

@MowMdown Thank you for your feedback. Reading through the entire thread again, I realize I opened whole separate can of worms like you said. I'm surprised that you recommended to enable "Host access to custom networks". Because earlier I came across a few posts in my search that mentioned not to enable this setting, posts claiming it would have no impact. I can't find them at the moment. Your advise makes sense, so I probably misunderstood it. Thank you. Still, I'm glad that it forced me to think of another solution; adding the static route to my router. Because it enables access to the custom docker network from any device on my network (192.168.123.0/24), instead of (I assume) only the Unraid host getting access to the custom docker network when I would have enabled the setting "Host access to custom networks". I assume that only the Unraid host would have access to the custom docker network, because I never tested it. Below the screenshots to illustrate the above. Static route within Unifi to custom docker network (172.19.0.0/24), named ProxyNet, pointing to Unraid host (192.168.123.10): Browsing from another device within 192.168.123.0/24 to Plex via custom docker IP 172.19.0.2 on port 32400: Browsing through Tailscale network via swag (wildcard certificate) and sub domain also works without specifying port: The reverse proxy, swag, is in the same custom docker network as Plex. So swag can reach it by container name and IP.

Sorry, to respond on an older threat. But I believe above to be incorrect. I came across this threat while trying to solve a problem. My Plex docker being only reachable when setup in network type host. But once I change it to a custom network so it can communicate with a reverse proxy (Swag), I can no longer reach it unless via Tailscale setup in that reverse proxy. But not without Tailscale. Looking at all the docker containers in use, I noticed that Plex doesn't have any ports mapped. Trying to solve this I found this thread and the comment above saying that port mappings don't do anything unless you are in bridge mode. Finally looking at official docker documentation on networks; https://docs.docker.com/engine/network/ I figured this was wrong. Doubting myselfI asked Grok AI for confirmation with the prompt/question: "Are docker containers running in a custom user-defined network reachable from the host's network without port mappings ?". The answer confirmed my understanding of the docker documentation; "Docker containers running in a custom user-defined network (e.g., a bridge network) are not directly reachable from the host's network without port mappings, unless specific configurations are made." So I followed through. I added the port mapping for port TCP 32400 to the Plex docker. The server results were that the Plex client found the server in a second, no longer did it take 15 seconds. The Remote Access section of the Plex server now has a green check mark again saying; "Fully accessible outside your network." Before it was a red warning. Using the IP address of the custom user-defined network I could not browse to the plex server yet. I had to add a static route on my Unifi router pointing the subnet towards the Unraid host. Once that was done I could use the custom user-defined docker network IP together with port 32400 to reach Plex web portal. And Tailscale using the DNS record also works. I'm happy with the results, although it took some time troubleshooting it all.

I have solved my cross flashing issue. But not after my favorite mainboard brand Gigabyte disappointed me. I learned how easy it is to make a USB pendrive EFI bootable. Just drop this binary into that flash drive FAT's root directory and rename it to <shellx64.efi>. Also, from Roderick W. Smith's site rodsbook.com I learned that Gigabyte's Hybrid EFI implementation is one of the worst that Mr Smith has encountered. So, if you have a Gigabyte mainboard forget EFI Shell, it probably won't work. It has cost me several hours today. I eventually solved it by inserting the LSI 9240-8i into the PCI Express x16 slot of an Asrock H81 Pro BTC mainboard. (A mainboard I almost forgot I still own. A relic from my scrypt mining days.) After entering the BIOS and going to the last menu "Exit", I selected the bottom option "Launch EFI Shell from filesystem device". It gave me a <SHELL> prompt. I selected my USB pendrive by typing "FS0:". I browsed to the location of my sas2flash.efi, 2118it.bin and mptsas2.rom files and executed the following two commands; sas2flash -o -f 2118it.bin -b mptsas2.rom sas2flash -o -sasadd 500605b0xxxxxxxx (replace the xx's with the SAS address from your card) Identical to BetaQuasi's M1015 Cross flashing instructions except that I used <sas2flash.efi> instead of <sas2flsh.exe>. Unraid 5.0.5 has identified the card and the attached drives. I'm a happy camper ! ;-)

First of all thank you all for the information provided on this forum. I have a LSI 9240-8i that I'm trying to downgrade to IT mode using the 9211-8i P19 firmware as described on the first page and the M1015 Cross flashing message from BetaQuasi. I managed to execute the megarec command listed below and reboot; megarec -writesbr 0 sbrempty.bin megarec -cleanflash 0 But when trying the sas2flsh commands I receive the error message "ERROR: Failed to initialize PAL" aka The PAL error. Another mainboard is not an option and I do not have an UEFI Shell option on my Gigabyte Z87X-UD3H mainboard, at least not that I'm aware off. I tried to create an bootable USB stick that would boot from UEFI, but I did not succeed yet. At the moment I'm trying a LinuxMint USB and the SAS2FLSH for Linux after spending hours looking for a UEFI boot option together with the SAS2FLASH.efi file. Tips and guides are welcome. Thank you in advance !