MowMdown

for example

This is what I currently have deployed and it works with my Intel gpu. immich-machine-learning: container_name: immich_machine_learning image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-openvino device_cgroup_rules: - 'c 189:* rmw' devices: - /dev/dri:/dev/dri networks: - proxy-net environment: - PUID=99 - PGID=100 - TZ=${TZ} volumes: - ${ML_CACHE_LOCATION}:/cache env_file: - .env restart: always healthcheck: disable: false

Longshot here but... How sure are you that you are not somehow shorting the board via the case/standoffs? Triple check the standoffs are installed in the correct spots and remove any (if possible) that do not align with the motherboards mounting holes.

Always post diagnostics and always refer to the unraid documentation, there are plenty of "How to do X" guides for specific issues such as disk replacement and upgrades. Anytime you rebuild a disk from parity, the contents of that disk will be overwritten including the filesystem to match what was recorded into parity. This means if a disk was previously reiserFS, parity will re-create that disk 1:1 resierFS and all. Follow JorgeB's advice and skip claude.

Your VPN stopped working. You should go to the binhex FAQ page by clicking on the container icon and clicking on support if you need further assistance.

Unless the cost savings is significant, I would not use SODIMM form factor on a desktop platform. Performance-wise it's objectively going to perform slower than standard DIMMs but for a media server it wont really matter. The PCIe bandwidth for the GPU and the GPU VRAM matters most for running a local LLM. 16GB of VRAM is going to be your biggest bottleneck

It's almost likely a plugin you have installed. One known plugin that causes this is the "Disk Activity" plugin.

In addition to the diagnostics the container's docker run output will also help.

There is a plugin you can install apparently. Otherwise you can update to 7.3.3 rc1 for a fix

Unraid always performs a parity check after an unclean shutdown (sudden reboot or power loss event)

I dont see how you're running out of 254 addresses on the default network size. Are you running more than 254 separate containers? furthermore you can create custom docker networks which would then get their own separate entire pool of IPs for example, look at bridge and proxy-net. these both have 512 addressable IPs per pool

You add two variables to the gluetunvpn container per the link I posted under the "qbittorrent example" section Name: Port Up Command Key: VPN_PORT_FORWARDING_UP_COMMAND Value: /bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":{{PORT}},\"current_network_interface\":\"{{VPN_INTERFACE}}\",\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences' Name: Port Down Command Key: VPN_PORT_FORWARDING_DOWN_COMMAND Value: "/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences' Just note where it references 127.0.0.1:8080 (in both) you need to change this to the host IP and qbittorrent host port to match your machine else it wont connect.

I’m curious why this is needed/is an issue? You should not be using the internal container IPs and there are better ways to address what I suspect you’re trying to do.

I’m almost certain any setting you change in the BIOS (including updating the bios or doing CPU swapping) will alter the fTPM ID and cause you to have to do the licensing dance.

Make sure the docker.img file is not located on one of your array disks Stop the array, go to settings, global share settings, and enable exclusive shares. In order for a share to go exclusive that share has to only exist on a single pool, if any folders or files are in multiple locations it won’t function as an exclusive share. This will allow you to continue to use /mnt/user/share instead of changing everything to /mnt/pool/share and will significantly lessen the effects of IOWAIT on the system due to FUSE overhead.