enesha

Heya - I had an extra m.2 slot on my mb, so I added a small 128 just to use for the boot drive. I ran the onboard and everything went fine, I boot and whatnot. Wasn't really happen about it, beecause I avoided internal boot as it uses TPM to tie it to my machine, which I do not approve of. I only saw that when I was rebuilding the USB boot and the website told me my license was ALREADY tied to my TPM...Without asking me or me ok'ing that change. So just throwing that out there, that was friggin annoying and pretty presumptious. So ik I did the intetnal..And now I see that it's using zfs. Don't remember getting that question in the onboard. Also noticed in another tunable to dedicate memory to zarc, but no option to disable that. Huh. So let me be clear. I do not want use ZFS. I do not want zarc taking up 2gb of ram. And most of all, i'm getting pretty teed off that these changes are happening without consent. Is there a way to do the internal boot without zfs? It's an absolute deal breaker. I don't wish to get into the debate about the usefulness of zfs. I don't want to be involved in discussion of a tainted kernel. What I do what is to know that I can undo that, and that decisions like what FS or anything else are not made FOR me. If I wanted a computer to make decisions for me I'd just install literally anything from MS. I have to say, slightly more generally, I am very disappointed here with the direction. I started with unraid so I was in control Slowly things keep getting tied back to corp. The machine checks in for licenses or whatever... things are tied to the damn website in ways they never were before. Very concerning. I came for the array and to get away from some corp snot somewhere making decisions for me that they they enforce. And this keeps moving in that direction it seems... So how do I kill zfs?

Yeah My bad. Didn't think of tha . Ah well. thought I did a search too but I guess I was deficient there. So - I did look there, and was able to find the solution (for me at least) and I will add it here just in case anyone runs across this in the future. It was simple, just change Extra Parameters to: --gpus all --runtime=nvidia that specific runtime was the key Thanks!

Hey guys, sorry for the long delay,. Yeah I resolved this. Turned out to be a problem with the MB. It decided on it's own to enable some OC for some reason. When I backed off all of that, it's working. Stupid Adus lol

Hey all So I have a container running ollama. Everything was working when I went to bed last night. This morning, I allowed the server o upgrade to rc1. Immediately thhe ollama container is failing with this: --gpus=all 'ollama/ollama' 3c5750fb5f4508a3bb986b33dabcf4b0c48aeaae14ccb3c6b0c95ef0e59b2f58 docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running prestart hook #0: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy' nvidia-container-cli: ldcache error: process /sbin/ldconfig failed with error code: 1 The container will not start. If I remove gpus=all it works on pure cpu. So I have tried: Reinstalling container. Changing back to r2. Downgrading driver and moving from closed to open, etc. Stop docker and restart docker service. Nothign worked. Maybe I didn't do those steps ina specifc order or something dunno.. Thoughts appreciated (update - whoops forgot diagnostics) companion-diagnostics-20260424-1308.zip

Well looks like maybe I'm in the wrong spot. While the CA ollama container causes the above referenced crash, I was able to install the LocalAI container and it shows both cards without any issue. So it appears that it's specific to how ollama is trying to detect the gpus. I tried asking in reddit r/ollama but seems that most have either not tried this, didn't have troubles, or were just not interested. So thanks for the assistance :)

Just an update - and I apologize for my confusion. I had no docker experience outside of unraid, and unraid makes it entirely too easy and user friendly lol.. I had previously only virtualized entire systems with kvm. Regarding those env options i reference that it wanted in the systemd, I assume i just missed something. They want you to include things such as: 'Environment="OLLAMA_GPU_LAYERS=-1" ' I assume that I could deal with that by adding it either as a variable under add path/variable etc, but also maybe just adding -e OLLAMA_GPU_LAYERS=-1 to the extra parameters.. Assuming that's correct, I feel stupid for that bit lol.

Heya again I've attached the diagnostic as requested. I've read the plugin help, and I believe that it's all correct. I am able to use the nvidia system for hardware transcoding in a jellyfin docker, and a few others. Additionally I can get ollama with one card to work, so it seems correct. When i've tried the NVIDIA_VISIBLE_DEVICES, I havn't even been able to get the container to start. using --gpus '"device=0"' worked fine, detects nvram etc , as does device=1. Separately. gpus=all results in it container throwing a timeout detecting gpu, and that's where things crash. I am also able to direct to the card directly via uuid with: --gpus device=GPU-609dbfeb-61f6-2d39-4166-99cb10673e54 I was unsuccessful in trying to get it to load if I try and define both cards by uuid. Maybe a syntax problem on my end. I know slack doesn't use systemd, but inside the docker it seems to use it. The container seems to be based on "DISTRIB_DESCRIPTION="Ubuntu 24.04.3 LTS" I reference the systemd file based on this website: https://markaicode.com/multi-gpu-ollama-setup-large-model-inference/ Under the "Essential Environment Variables" section. Now as I read that site, they are obviously not using a container, it seems they are just running it directly from the terminal, which indicated to me then that if it needed that file, that it's within the root fs inside the container. Honestly I never really used Docker before playing with it on unraid, so my experience and knowledge of it is pretty slim.. nvidia-smi attached as txt to enhance readability nvidia-smi -L reports : GPU 0: NVIDIA GeForce RTX 3060 (UUID: GPU-609dbfeb-61f6-2d39-4166-99cb10673e54) GPU 1: NVIDIA GeForce RTX 3050 (UUID: GPU-29500f42-d1df-ba5c-32f2-a32e97a0cfcf) lspci -v is also attacted (only the nvidia parts) as txt . Note it does show noveau, as I tried several versions of the driver, and have just left it at the open version right now. From inside the container this is what I get, log wise, from using one card: time=2026-01-25T03:40:23.012Z level=INFO source=types.go:42 msg="inference compute" id=GPU-609dbfeb-61f6-2d39-4166-99cb10673e54 filter_id="" library=CUDA compute=8.6 name=CUDA0 description="NVIDIA GeForce RTX 3060" libdirs=ollama,cuda_v13 driver=13.0 pci_id=0000:01:00.0 type=discrete total="12.0 GiB" available="11.6 GiB" time=2026-01-25T03:40:23.012Z level=INFO source=routes.go:1725 msg="entering low vram mode" "total vram"="12.0 GiB" threshold="20.0 GiB" That's the same for the 3050, other than 8GB. It's when both cards are defined it attempts to "time=2026-01-25T03:40:18.867Z level=INFO source=runner.go:67 msg="discovering available GPUs..." After that there is no contact to the cards, and it reports that discovery timed out before completing. I can get that exact error later, if I try it right now it'll crash things, and people are staying warm watching some media from it now :) lspci doesn't seem to be available inside the docker. At least i couldn't load it uname -a indicates it's using the unraid kernel "Linux 5284ec90a273 6.12.54-Unraid #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025 x86_64 x86_64 x86_64 GNU/Linux" running nvidia-smi (-L) inside the container displays the smae information, but only for the card that is exposed to it. So it only seems to have trouble with both cards. Strange. It doesn't throw an error to the unraid syslog But thanks for trying still :) diagnostic.zip nvidiasmi.txt lspci.txt

Thanks for the reply! I'll say I was assuming a lane thing. Got me to upgrade the bios and root around a little more. Fixed some other random annoyances while I was in there. However that doesn't seem to be the problem. I changed what I could, and moved around the m2's. After hours of move boot blah nothing changed. I confirmed that I can use either card individually when exposed one by one to the container. No fail on 0 or 1. It's only when I try and expose both cards with gpus=-all that things fail. So I guess i've narrowed down to a problem with that particular comtainer and whatever it is doing. I saw suggestions to edit a systemd file, but if that's inside the container and not the appdata, it's ephemeral and just poofs out on restart of the container..Right?

Good morning all I'm having weirdness, and I am not sure where exactly to go, as the problem could be coming from many things. So here we go. I am running Unraid 7.2.3 on an Asus z790-ayw motherboard. I have just upgraded my GPU from a nvidia 3050 8gb card to a nvidia 3060 12gb. The 3060 is more than just more memory, it moves form the 4 lanes of my 3050 to 16 lanes. I currently have the 580 nvidia driver. Had the same problem on 590. I have 2 m.2 devices installed on m2_2 and 3 slots. The goal was to have both cards installed to combine the vram in ollama to get 20gb to load larger models. The computer works as expected with just either card as solo. Testing I had installed the 3060 on pcie-1 and 3050 installed in pcie-3 Computer functions as desired to that point. I am able to reboot with both cards, and get into unraid just fine. Before I do anything, I can get both cads reported by nvidia-smi -L. I can load up the majority of my docker containers and there seems to be no problem - including starting jellyfin with hardware tc. Next I try to start the ollama instance. This is where things go bad rapidly. ollama (with --gpus=all) tries to enumerate the cards, and it fails. The error is one of basically timeout while searching for the cards. It then attemps to enable cpu only as the container gets caught in some molass here. Stopping the container at that point is particularly hard, and it seems to kill the container (I tried gui, cli and dockhand) i have to actually go and completely disable the docker service, before it closes down. At this point, trying to run nvidia-smi has the app just stall and never return the card info. I can only regain control by forcing a reboot. This is where it gets even more ridiculous. When I try to reboot at that point, the server gets into a loop, unable to unmount /mnt/cache. I have tried closing anything that might be on the drive. using lsof to see what might be open, and still cannot manually unmount the drive. It also gets caught up being unable to restart docker with the docker img loaded as /dev/loop2 and unable to kill it, so the service wouldnt restart anyway. After forcing it, it'll reboot just fine. I somewhat suspect that it's one of the m2 slots sharing the lanes from pcie-3, but cant verify. I checked the info here: https://www.asus.com/us/support/faq/1037507/ to read up on the bifurcation in case that is the problem. From that, and inside the uefi, it seems like bifurcation is only able to be triggered on pcie-1, which is obviously not what i need I have reset the bios to defaults. I am unable to try gpu2 in the lower pcie slot, as the heatsink and whatnot come up against the header for the front usb ports, and a couple of the sata ports, making it practically impossible to place the card there. I'm just sorta lost. At first glance, it seems like a hardware issue, but things seem to work until ollama tries to search for gpus. However the hang on /mnt/cache happens ONLY after the init attempt. So I'm just not sure which direction to head towards for help, so I started here. Does anyone have any thoughts on the problem? Even if it's just to suggest that I need to check around the docker sphere, or...Well I dunno. A hearty thanks in advance for any thoughts you might have, no matter how small or out there. It's just weird. THANKS :)

Just to add to it, I did get some leads when I was on the jf forums. They didn't specifically mention unraid, but they had suggestions on what to add. They said to append group_add in the config. Specifically what they said that this should be the docker compose below. However I have no idea what to do about that in unraid..., "version: '3' services: jellyfin: container_name: jellyfin image: jellyfin/jellyfin restart: unless-stopped user: ${PUID}:${PGID} environment: - TZ=${TIMEZONE} volumes: - ${CONFIG_FOLDER}/jellyfin:/config - ${CONFIG_FOLDER}/temp/jellyfin:/cache - ${LIBRARY_FOLDER}/series:/series - ${LIBRARY_FOLDER}/shows:/shows - ${LIBRARY_FOLDER}/movies:/movies group_add: - 26 # Video group - 303 # Render group devices: - /dev/dri:/dev/dri ports: - 8096:8096 - 7359:7359/udp # Optional - Allows clients to discover Jellyfin on the local network."

Afternoon all Sorry to write in general support, I couldn't seem to find a specific thread for the Official release. I use that as it does seem easier for hardware tc. But I wager this is a ore general problem anyway So I've looked for days for a solution. The problem is that I have the official jf docker, and I can't seem to change the uid and pid. I have definitely set the PUID and PGID in the settings, even tried adding just uid and a few other thing that I found in the wild and no luck. The problem being that since it';s reading and writing as root, it's causing headaches. I add things to the library after ripping, by using double commander to move them into place. No problems. I have tinymediamanager scanning the library and changing names and adding images etc. Jelly sees everything just fine. The trouble is when jelly tries to add file. The worst offender is the trickplay, but it happens on other files as well. When I add the file to the server, it jumps into play and very quickly starts adding images and generating trickplay. Often this happens very quickly, before i have a chance to hit it with tmm. Especiall if I am adding a few files at a time. When it writes the trickplay or nfo or whatever, when tmm gets around to changing names and cleaning up the directories, it suddenly cannot remove the files that jf generated so they are getting orphand. Sometied just an nfo or jpg, but entire trickplay directories with the wrong name. I have been getting around it by more manual edits,. and changing permissions in bulk to let tmm or me on nfs so what needs to be done. tmm is running in a vm on my secondary server, connecting to the library over nfs. Works Great. JF is using the directories passed directly from the docker settings. No matter what I do, I can' get it to respect 99:100. Everying is 0:0. Maybe I';m missing something, I dunno. I'd definitely appreciate any suggestions. Thanks and Happy New year to all even if you don't reply ;)

Hiya Hrm, very interesting....My theory was that the folder would allow docker to use all available space. Ah well Followed your instructions, and things worked out great. Thanks!

Morning all Running 7.2.1-rc.1 so maybe that's my problem? So I have docker properly installed and running. The containers I have all are running properly, and I am able to update those containers properly. I have pleanty of space available. I am able to install random others as a test, and they install properly...i.e. pia However, when I try to install the vaultwarden server container, using either the default or alpine, I get this error: Error: failed to register layer: Failed to create btrfs snapshot: invalid argument Weird Just wondering if anyone else on here has an idea of what's up. I thought about posting this in the vaultwarden support section, but wasn't sure if this was something of theirs...Since it never fully installed I assumed it an unraid problem... I've attached the recent diagnostics Thanks! companion-diagnostics-20251118-1018.zip