Rian Kelly

To expand on the port mapping: the format in docker-compose is always host_port:container_port. Looking at the ResourceSpace Docker image, it runs Apache on port 80 inside the container. Your compose file needs to map an external port to that internal port 80. If you had: ports: - "8095:8095" That maps host port 8095 to container port 8095, but nothing is listening on 8095 inside the container. Apache is on 80. Change it to: ports: - "8095:80" Then access it at http://your-unraid-ip:8095 You can verify the container is running and what ports are exposed with: docker ps The PORTS column will show the mapping. If it shows 0.0.0.0:8095->80/tcp then the mapping is correct. One other thing to check on Unraid specifically: make sure no other Docker container is already using port 8095. Go to the Docker tab in the Unraid WebGUI and check the port assignments for your existing containers. Port conflicts will cause the container to fail to start silently.

Glad you found it. For anyone else hitting this: the reason Unraid changed the NIC model is that the VM editor resets certain fields to their defaults when you modify other settings like CPU pinning. The current default NIC model in Unraid 7.x is virtio-net, which replaces the older e1000 default. When pfSense boots with a virtio-net NIC instead of e1000, it sees an entirely different network device (vtnet0 instead of em0/igb0). Since pfSense's interface assignments are tied to the device name, it loses all its WAN/LAN configuration because the expected device no longer exists. To prevent this in the future: after making any VM edit in the Unraid GUI, always check the XML tab before saving. Look for the <interface> section and verify the model type is still what you expect: <model type='e1000'/> If the GUI changed it to virtio-net and you want to keep e1000 for compatibility, switch to the XML view, fix it, and save from there. Alternatively, you can switch pfSense to use virtio-net permanently since it has better performance than e1000, but you will need to reassign your interfaces in pfSense (Interfaces > Interface Assignments) to map vtnet0/vtnet1 to WAN/LAN.

The reason your 2080 is not selectable for binding is that IOMMU Group 2 contains other devices alongside the GPU. For VFIO passthrough to work, you need to bind the entire IOMMU group to vfio-pci, and Unraid won't let you bind a group that includes critical system devices (like the root port or other PCI bridges). Two approaches: 1. ACS Override (quick fix): Go to Settings > VM Manager and set "PCIe ACS Override" to "Both" or "Downstream". This tells the kernel to treat each device as its own IOMMU group, splitting up the shared group so the GPU can be isolated. After applying, reboot and check System Devices again. The 2080 should now appear in its own group and be selectable. The trade-off: ACS override reduces IOMMU isolation guarantees. In a home lab this is fine, but it means devices in the split group could theoretically DMA into each other's memory. For a home GPU passthrough setup this is a non-issue in practice. 2. Physical slot change (cleaner fix): If your motherboard has multiple x16 slots, try moving the GPU to a different PCIe slot. Different slots often land in different IOMMU groups depending on your chipset layout. Some slots connect through the CPU directly (cleaner grouping) while others go through the chipset (shared groups). Check which devices share Group 2 by looking at the System Devices page. If it is just the GPU plus its audio function (NVIDIA audio), that is normal and both should be bound together for passthrough.

To expand on the path issue: /mnt/user in Unraid is a FUSE union mount that merges all your array and pool shares into a single namespace. Creating directories directly under /mnt/user (like /mnt/user/real-debrid) instead of inside a proper share breaks things because those directories exist only in the FUSE layer and disappear or cause conflicts when the array restarts. The fix: create a proper share through the Unraid WebGUI (Shares > Add Share), for example "real-debrid", and then reference it as /mnt/user/real-debrid in your Docker container path. The difference is subtle but important: a proper share has backing storage on a disk or pool, while a bare directory under /mnt/user is just a phantom. For the Docker containers disappearing after reboot, the docker.img file is likely being recreated empty on each boot. Check Settings > Docker > Docker vDisk Location and make sure it points to a cache pool or a specific disk path, not to /mnt/user. If the Docker image sits on the array and the array takes too long to start, Docker gives up and creates a fresh empty image. After fixing the path, you can reinstall containers from Community Apps > Previous Apps. To avoid this in the future, keep regular backups of your Docker template configurations with the CA Backup plugin. It saves all your container configs so reinstallation is just a click.

The xlog_recover_items_pass2 error with error 117 (EUCLEAN) means XFS is refusing to replay its journal because it detected corruption in the log itself. This is recoverable but needs care. Good news: DiskInternals reading the physical disk successfully means the disk hardware is fine. The issue is either the emulated reconstruction introduced log inconsistency during the parity rebuild, or Disk 9 had an unclean shutdown that left the journal in a state the kernel cannot safely replay. Steps to try: First, from the Unraid terminal while the array is started (even in degraded state), run a dry-run check without changing anything: xfs_repair -n /dev/md9p1 Second, if that shows repairable errors, run it without the -n flag: xfs_repair /dev/md9p1 If xfs_repair itself complains about a dirty log, you may need: xfs_repair -L /dev/md9p1 This zeros the journal, which loses any in-flight writes from the last session but the data on disk stays intact. For Disk 6 being unmountable after rebuild: run the same xfs_repair -n /dev/md6p1 dry run first. Post the output from both so we can see what the repair tool finds before you commit to changes. Also worth running smartctl -a /dev/sdX on the physical Disk 9 device to verify no underlying hardware errors appeared.

The slot shadowing on HP ProLiant servers is well documented — certain PCIe slots share lanes with the onboard SATA/SAS controller or storage backplane, so inserting a card in those slots disables the storage port. It's not a BIOS setting you can change, it's a hardware mux decision the board makes. To identify which slot is the problem without guessing: look in the diagnostics ZIP for syslog or lspci output. You'll see the drives disappear from the device tree, and the storage controller may still show but with no attached devices. The HP iLO event log (if attached) would confirm a slot power event coinciding with the drive loss. For the G7/G8/G9 generation ProLiants, the typical rule is: - Slot 1 (closest to CPU): shares bandwidth with the embedded storage controller - Slots 2-4: typically safe for add-in cards But the exact mapping depends on your specific model. The HP Quickspecs or the server's User Guide has a PCIe slot dependency table — searching for your model number + "PCIe slot dependencies" on the HP BIOS site usually pulls it up directly. Quickest fix: move the NIC to the next available slot and see if drives come back without needing to change any BIOS settings. If you have a 331i or similar embedded 4-port NIC already, you may be able to use those ports at 1G while you figure out placement, and then migrate the 2.5G NIC to a non-conflicting slot. Once drives are back, confirm with lspci | grep -i ethernet in the unRAID terminal that both controllers show up, and check the network speed with ethtool eth1 (or whichever interface the new NIC gets).

Since the procedure question didn't get a direct answer — the migration is straightforward but requires a full data offload first since there is no in-place conversion between ZFS and BTRFS. Steps: 1. Back up all data from your 3 pools to temporary storage (another drive, network share, whatever you have). Parity does not protect pool disks so treat this as mandatory rather than optional. 2. Stop the array. 3. In the Main tab, click on each pool disk. Change the file system from ZFS to BTRFS and click Format. This wipes the disk and creates a fresh BTRFS filesystem. 4. Start the array. 5. Restore your data back to the newly formatted pools. One thing worth planning for: if you were relying on ZFS snapshots, BTRFS does have snapshot capability (btrfs subvolume snapshot) but Unraid's UI doesn't expose it directly. You would manage BTRFS snapshots from the CLI or a user script. Worth checking whether whatever you were using to trigger ZFS snapshots has a BTRFS equivalent before committing to the migration. After the switch you should see write performance closer to what your drives are actually capable of.