bmartino1

tired that,.. still cant... cleared brower data, differet browser... Its NOT a cahed page issues.. its permsion based form what I can find... or auth based... I login via the google conection... while i ahve a username/passowrd and mfa code that can also work... again this appears to be froum area specfic...

Yo can forum PM me if needed with data you may not want public... IT looks like you installed the offical plex inc docker. which is baed off of linux server insital structure. with the plex docker running install my docker: keeping the defaults are fine... and should work but the Plex sytem docker need to be ruinning when my do ker installs/runs. a sucessful run should look like this: text error warn system array login [2026-11-08T00:52:19Z] Candidate: Plex-Media-Server (plexinc/pms-docker), id=44f391096107 [2026-11-08T00:52:19Z] Target: name=Plex-Media-Server image=plexinc/pms-docker id=44f391096107 mode=auto [2026-11-08T00:52:19Z] Paths: mount=/config relative=Library/Application Support/Plex Media Server databases=/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases [2026-11-08T00:52:19Z] Mounts: [{"Type":"bind","Source":"/mnt/user/appdata/Plex-Media-Server","Destination":"/config","Mode":"rw","RW":true},{"Type":"volume","Source":"/var/lib/docker/volumes/5ca676d479a2fb73b771c3fe55553d2d33217fcbc6f3877a7b28da41e27e1726/_data","Destination":"/transcode","Mode":"","RW":true}] [2026-11-08T00:52:19Z] Restart policy: no [2026-11-08T00:52:19Z] Original Plex container running=true [2026-11-08T00:52:19Z] Checking latest official DBRepair release for Linux-x86_64 [2026-11-08T00:52:20Z] Downloading official DBRepair v26.10.00 (DBRepair-26.10.00-Linux-x86_64.zip) /tmp/dbrepair-download.SMkdxHat/DBRepair.zip: OK [2026-11-08T00:52:21Z] DBRepair v26.10.00 downloaded from ChuckPa's official GitHub release [2026-11-08T00:52:21Z] DBRepair version: DBRepair v26.10.00 DBRepair v26.10.00 [2026-11-08T00:52:21Z] Requesting supported PMS shutdown via DBRepair stop [2026-11-07 18.52.21] Database Repair Utility for Plex Media Server (Docker) [2026-11-07 18.52.21] Ver 26.10.00 (Oct 16 2026) - PMS Version = +1.43.5.11029 [2026-11-07 18.52.21] [2026-11-07 18.52.21] Stopping PMS. (60 second max delay) [2026-11-07 18.52.22] Stopped PMS. [2026-11-07 18.52.22] [2026-11-07 18.52.22] Exiting. [2026-11-08T00:52:22Z] Waiting up to 90 seconds for PMS to exit [2026-11-08T00:52:22Z] Creating cold backup of Databases before maintenance (including SQLite WAL files) Backup saved: /config/Library/Application Support/Plex Media Server/DBRepair-Backups/dbrepair-pre-auto-20261108T005222Z.tar.gz [2026-11-08T00:52:22Z] Executing mode=auto; max duration=7200s [2026-11-07 18.52.22] Database Repair Utility for Plex Media Server (MANUAL) [2026-11-07 18.52.22] Ver 26.10.00 (Oct 16 2026) [2026-11-07 18.52.22] Databases = '/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases' [2026-11-07 18.52.22] PMS Version = '1.43.5.11029' (Schema Loaded) [2026-11-07 18.52.22] [2026-11-07 18.52.22] Checking the PMS databases... [2026-11-07 18.52.22] Main DB is OK. [2026-11-07 18.52.22] Blobs DB is OK. [2026-11-07 18.52.22] [2026-11-07 18.52.22] Checking Main DB for orphaned media items [2026-11-07 18.52.22] No orphaned media items found [2026-11-07 18.52.22] [2026-11-07 18.52.22] Exiting. [2026-11-08T00:52:22Z] DBRepair finished successfully [2026-11-08T00:52:22Z] Restoring Plex using Docker restart (independent of image's internal supervisor) [2026-11-08T00:52:30Z] Finished exit=0; log=/logs/dbrepair-20261108T005219Z-7.log ** Press ANY KEY to close this window ** I'm not sure how you got that error. After re-reviewing the posted log, I assume the Plex Docker wasn't running when Plex Repair ran.

looks like you may have edited the default pelx configuration pathing... my auto-detect image didn't find the Plex Docker either... per logs given... Per unraid defaults per log line: [2026-11-07T01:19:00Z] Paths: mount=/config relative=Library/Application Support/Plex Media Server databases=/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases may need to be updated for your layout... since noe iamge was detected above either and the scirpt was left to its own devices and it coundl't find your plex docker... per log line: DBRepair unable to match schema - Features degraded as i atempt to use docker inspect adn other per how the env is setup to auto-detect and determine this... something failed... and the Plex version you're running may be too old for the latest release of the db repair script: [2026-11-06 17.19.02] WARNING: PMS version not recognized. Some checks minimized. Contact ChuckPa. I would need your Pelx template data, the image tag name you're using and pathing that differs from the defaults to go over the edits needed to let it run. Although I think your plex version is outdated given the error per chuck pa script. all this project aims to do is use Unraid WebUI options gui to pre-run the script per your settings. Most can be auto-detected by my wrapper and feed the script the data needed... https://github.com/ChuckPa/DBRepair Per chuck release and wiki: DBRepair now contains database knowledge for versions 1.18.2 and above. so your version may not be the updated plex version ... also per there wiki the working docker iamges for plex and his script: Currently supported container images: Plex, Inc. LinuxServer HotIO BINHEX Containers are entered with docker exec. so if you're outside of these points then this Docker will not run as its only an environment meant to help streamline and keep end users out for the terminal and running weird unkonw command and scripts... Again, I would need the docker run / template data of your current plex to get this. You would hit edit to your Plex container and at the bottom there is an Apply (if template auth mod is enable you can hit Save...) Otherwise make a small change and change it back so na change is made but the Apply button can be hit... This will take you to an Unraid build screen; I need the data from that... *PLEASE PARSE that screen do NOT share your PLEX CLAIM KEY! but without that, I can't explain what went wrong where... and per the script data, I would advise you to reach out to Chuck PA. who may ask similar questions and need the data... https://github.com/ChuckPa/DBRepair/issues

and again it may already stil be in the active xorg.conf... you will have to double check that.. Now that I can confrim that yes you saved and reboted and its at its fresh confiruagtrion no random edits.. thers a few things as outlined int eh feature request... What you want is to determine whether /etc/X11/xorg.conf is still being generated and, if so, force Xorg... echo "=== NVIDIA PLUGIN SETTING ===" cat /boot/config/plugins/nvidia-driver/settings.cfg echo echo "=== ACTIVE XORG CONFIG ===" ls -la /etc/X11/ echo cat /etc/X11/xorg.conf 2>/dev/null || echo "No /etc/X11/xorg.conf" echo echo "=== XORG CONFIG FRAGMENTS ===" find /etc/X11/xorg.conf.d -maxdepth 1 -type f -print -exec cat {} \; 2>/dev/null echo echo "=== GPU PCI DEVICES ===" lspci -nn | grep -Ei 'VGA|3D|Display' echo echo "=== XORG GPU SELECTION ===" grep -Ei 'NVIDIA|ASPEED|Intel|AMD|modeset|BusID|PrimaryGPU|OutputClass' \ /var/log/Xorg.0.log 2>/dev/null The important part is /etc/X11/xorg.conf. If you see something resembling: Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BusID "PCI:..." EndSectionthen we've found the problem: NVIDIA is still getting written into the active Xorg configuration despite disable_xconfig=true. So if 7.3.4 is producing an NVIDIA xorg.conf anyway, that's a meaningful behavioral change/regression rather than your setting simply being wrong. in which you will need to post your diag and make a bug report... once again, not enoth data.. but you would then edit the go file on teh flash drive to run a script to adjust this... The goal is to: Keep the NVIDIA Driver plugin installed for Docker/GPU workloads. Force the Unraid local GUI (Xorg) to use the iGPU. Make the configuration persistent across reboots. Avoid modifying Unraid's temporary root filesystem permanently. ... 1. Identify the iGPU PCI BusID Run: lspci -nn | grep -Ei 'VGA|3D|Display'Example: 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 01:00.0 VGA compatible controller: NVIDIA CorporationHere the Intel iGPU is 00:02.0, which Xorg represents as PCI:0:2:0. 2. Update /boot/config/goEdit the existing /boot/config/go file and insert this block before its existing /usr/local/sbin/emhttp & line. # ===================================================== # Force Unraid GUI onto iGPU instead of NVIDIA # ===================================================== # Change this to match the Intel/AMD iGPU PCI BusID IGPU_BUSID="PCI:0:2:0" # Ensure NVIDIA plugin does not generate its own xorg.conf NVIDIA_CFG="/boot/config/plugins/nvidia-driver/settings.cfg" if [ -f "$NVIDIA_CFG" ]; then if grep -q '^disable_xconfig=' "$NVIDIA_CFG"; then sed -i 's/^disable_xconfig=.*/disable_xconfig=true/' "$NVIDIA_CFG" else echo 'disable_xconfig=true' >> "$NVIDIA_CFG" fi fi # Configure Xorg to use the integrated GPU mkdir -p /etc/X11 cat > /etc/X11/xorg.conf <<EOF Section "ServerLayout" Identifier "UnraidLayout" Screen 0 "iGPUScreen" 0 0 EndSection Section "Device" Identifier "iGPU" Driver "modesetting" BusID "$IGPU_BUSID" EndSection Section "Screen" Identifier "iGPUScreen" Device "iGPU" EndSection EOF echo "Unraid GUI iGPU Xorg configuration applied: $IGPU_BUSID"This uses the generic Xorg modesetting driver, suitable for an Intel or AMD iGPU with working kernel DRM support. The resulting active file will be: /etc/X11/xorg.conf The NVIDIA driver remains installed; this configuration only directs the Xorg display server toward the iGPU. 3. Verify after rebootcat /etc/X11/xorg.conf grep -Ei 'modeset|NVIDIA|BusID|Screen' /var/log/Xorg.0.log This is asumming its a xorg issues.... you can even call the nvidia-xconfig and edits... to confirm your config.. that may be a new pathign for the config based on updated code... still, the point being not enoth info...

in fact, Immich has made a Docker compose builder where one can preselect pathing. https://immich.app/docker-compose-builder?advanced=true&storage.customFolders=true one can then add the additional pre-load or use Compose Docs and add additional options in the compose manager to update the labels to fit their needs... Example of an additional label to make the web UI pre-fill... labels: net.unraid.docker.icon: 'https://raw.githubusercontent.com/imagegenius/templates/main/unraid/img/immich.png' net.unraid.docker.webui: http://[IP]:[PORT:2283] folder.view: immich net.unraid.docker.managed: 'composeman'

Sorry, life's been busy. Yes, you can absolutely keep the Immich application/database data on your SSD-backed appdata share while putting the actual photo library in a separate Unraid share. Also, thanks for bringing this up because I need to update my guide. Immich's current official Compose file has changed since the version my guide was based on, and Compose Manager Plus has replaced the old Compose Manager plugin. following: https://bmartino1.weebly.com/immich-on-unraid-docker-compose-guide.html current compose example tags and min data: https://github.com/immich-app/immich/blob/main/docker/docker-compose.yml in the compose you would change the path to the desired place for your ssd here: immich-photos: driver: local driver_opts: type: none device: /mnt/disk/ssd/path...etc o: bind To further answer your questions. 1. Stack directory vs. photo storageThe Stack Directory is not the directory that all of your Docker data has to live under. I would leave the stack directory as: /mnt/user/appdata/immichYou do not need to change the stack directory to /mnt/user. In fact, that's ill-advised; you will lose data that way... The stack directory is basically where Compose Manager Plugin keeps the files that define/manage the stack. ie your compose file, .env, and related stack configuration. Docker bind mounts can point somewhere completely different on the Unraid host as mentioned above in the compose. For the layout you want, something like this is perfectly reasonable: /mnt/user/appdata/immich/ <- Compose/config/database on SSD/cache (default unriad pathing) /mnt/user/immich_photos/ <- Immich media share so no, please update the stack directory. With additional Docker Compose docs, a Compose configuration, that could be easier than the direct placement. I've found in testing that is was better to be Compose-specific... https://docs.docker.com/compose/ Example: we could supply them in the environment file or compose directly... to explain how the env fills in the compose file... In the .env file you would set: UPLOAD_LOCATION=/mnt/user/immich_photos DB_DATA_LOCATION=/mnt/user/appdata/immich/database/postgresThen update the current weebly supplied Immich compose file then uses teh suppliced volumes at the bottom: services: immich-server: volumes: - ${UPLOAD_LOCATION}:/data database: volumes: - ${DB_DATA_LOCATION}:/var/lib/postgresql/dataSo you can keep PostgreSQL on the SSD/cache-backed appdata share while the much larger Immich media library lives in its own immich_photos share. That is preferable to changing the whole Stack Directory to /mnt/user... My existing guide currently does this differently using named volumes with driver_opts, for example: immich-photos: driver: local driver_opts: type: none device: /mnt/user/appdata/immich/photos o: bindThat method works as a Docker bind-mount mechanism, and changing device: to /mnt/user/immich_photos would accomplish what you're asking. However, for a new installation I would now follow Immich's current configuration and use UPLOAD_LOCATION instead. It is simpler and matches what the Immich maintainers currently document. https://docs.immich.app/guides/custom-locations/ One other important distinction: Immich's UPLOAD_LOCATION contains more than just the original photographs. Immich maintains its own directories underneath /data for things such as the library, uploads, thumbnails, encoded video, profiles, and backups. If you want to split those onto different physical storage locations, Immich supports that too, but I would not complicate a first installation unless you have a reason to. For your stated goal, putting the whole Immich media location at: /mnt/user/immich_photosis the simple solution. Then let Unraid's share/cache settings determine whether that share lands on cache first and later moves to the array. That part is an Unraid storage-policy decision rather than an Immich setting. I would keep the PostgreSQL database on SSD/cache. I would also make sure that database location is included in your backup strategy — the database and the media library are both important parts of an Immich installation. 2. Compose Manager vs. Compose Manager PlusYes, this part of my guide also needs updating. The original Docker Compose Manager plugin has been deprecated. Compose Manager Plus is its maintained replacement/continuation and was specifically designed as a drop-in replacement. It even retains the same underlying project structure so existing stacks can be detected. (tested this myself) while the webbly guide can guarantee a first one its setup for all in one area for all-in-one simplicity. alot of other users ahve made a ca mess and teh uriad docs are semi compelte online... my compose just adds some additional settings (Labels) to make things look nice and confirm wokr forma 1 click and go... offical immich docs on it: https://docs.immich.app/install/unraid/ and have not updaded to the better plugin due to their documentation... since then i tired to maintain guides, update and issues on the forum and left due to other users... I will still gladly help where i can... to me its clear others have taken up the mantle and other new guides exist but nothing clear cut. as theres a lot of customization and more docker control in a Compose file... For a new installation today, use Compose Manager Plus plugin. https://forums.unraid.net/topic/197334-plugin-compose-manager-plus/ For the basic Immich setup, you generally don't need to change all of the additional advanced options just because they're now exposed by the newer plugin. Keep the Immich stack itself at: /mnt/user/appdata/immichand control where Immich actually stores its data through the Compose file and .env. as explained abit above... In other words, think of the two settings separately: Compose Manager Plus Stack Directory: /mnt/user/appdata/immich Immich .env UPLOAD_LOCATION: /mnt/user/immich_photos Immich .env DB_DATA_LOCATION: /mnt/user/appdata/immich/database/postgresThat gives you basically the layout you originally wanted without making /mnt/user the root of the Compose stack. I'm still debating on updating my guide because both Compose Manager Plus and Immich's current official Compose configuration have moved on since I wrote that version. For new installations, I would now stay much closer to Immich's current release docker-compose.yml and .env rather than maintaining unnecessary custom volume definitions. I hope that answer your questions and goes over it a bit better.

did you reboot after saving? as it may be in teh actrive xog.conf now...

more info needed. not sure your writing the corect setting int eh corect area... see featurerequest/bug report and side troubleshotting https://product.unraid.net/p/local-gui-gpu-output-selection#comment-400402 One thing worth checking is the Unraid NVIDIA Driver plugin. By default, it can run nvidia-xconfig and create /etc/X11/xorg.conf, which may cause Xorg to attach to the Quadro. Similar Unraid cases have been resolved by setting: disable_xconfig=truein: /boot/config/plugins/nvidia-driver/settings.cfgAfter that, a custom Xorg configuration could explicitly target igpu...

debain was taking quite some time with latter openssh servier udpates decided to push the docker iamge though to be patched. this also added time to update adn fix a few side back burner features such as docker env webui passord teamptle will chagne and update passord for admin sftp users at edit save runs... Test results Test Result OpenSSH 10.6p1 PASS OpenSSL 3.6.5 PASS Fail2Ban 1.1.1 PASS Entrypoint and script syntax PASS Reject default ADMIN_PASS=admin PASS Accept a custom admin password PASS Write admin account into users.conf PASS Correct UID/GID 1000:100 PASS Create /home/admin/sftp PASS

new repo updates cahgnes and fixes.... full web ui rewrite.

decided the netprobe web ui needed a overhaul it was getting a bit clunky... major updates were made and added to the new interface. new auth access guest read only. webui trubs docker envs. docker env can help set or make inital configurations... https://github.com/bmartino1/NetProbe_Python overall a nicer format, same data, same testing but all webui intergrated... unraid tempatle update may be made... iniatl web ui and docke iamge have been updated.

In conclusion: With NVIDIA moving Maxwell, Pascal, and Volta into legacy support, I think there is an important compatibility consideration for Unraid users who continue to rely on these GPUs, particularly for hardware transcoding and other Docker workloads. NVIDIA has officially confirmed that the 580.xx Linux driver series is the last branch supporting Maxwell, Pascal, and Volta. However, this is not an abandoned driver branch. NVIDIA has designated R580 as a Long Term Support branch through June 2028 and explicitly states that compatibility updates for newer Linux kernels, along with critical bug fixes, will continue during its remaining support lifetime. Source: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ This becomes relevant as Unraid continues advancing its Linux kernel. Unraid 7.2.4 used kernel 6.12.54, while Unraid 7.3.0 moved to 6.18.29. The recent 7.3.4 release now uses 6.18.58. These changes introduce an additional compatibility requirement for NVIDIA's proprietary kernel modules and the Unraid-specific driver packages. We have already seen reports of NVIDIA driver installation or functionality problems during Unraid upgrades. One reported issue involved a Pascal-based Quadro P1000 running driver 580.159.03 after upgrading from 7.2.4 to 7.2.5. Another report involved the NVIDIA Driver plugin selecting or downloading an unexpected driver version during an upgrade to 7.3.2. Importantly, NVIDIA has continued releasing fixes for kernel compatibility, including a Linux 6.19 module-build fix in 580.126.18, a Linux 7.1 build fix in 580.159.04, and a DKMS installation fix in 580.173.02. I think there are two distinct concerns here: whether NVIDIA's maintained legacy driver supports a given Linux kernel, and whether a properly compiled and selectable Unraid driver package is available for that particular kernel release. Those should not be treated as the same problem. It would be helpful for Unraid to maintain a compatibility reference identifying which 580-series driver packages are available and verified for each supported Unraid kernel, particularly as newer NVIDIA production drivers no longer support Pascal GPUs. I am not suggesting that Unraid should stop updating its kernel, especially considering the security fixes in these releases. Rather, I think the legacy GPU transition warrants clearer compatibility documentation and a reliable path for retaining a supported 580-series driver during upgrades. Otherwise, users with otherwise functional hardware risk losing GPU-dependent workloads because of driver packaging or upgrade-handling issues rather than because NVIDIA has actually ended support for their architecture. Relevant references: NVIDIA legacy GPU support: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ NVIDIA driver lifecycle: https://docs.nvidia.com/datacenter/tesla/drivers/latest/supported-drivers-and-cuda-toolkit-versions.html Unraid release notes: https://docs.unraid.net/category/release-notes/ Unraid NVIDIA driver packages: https://github.com/unraid/unraid-nvidia-driver/releases Reported 7.2.5 Pascal issue: https://product.unraid.net/p/upgrade-to-7-2-5-breaks-nvidia-driver-v580-159-03 Reported 7.3.2 plugin selection issue: https://forums.unraid.net/topic/200537-nvidia-driver-plugin-support/

Expanded Unraid kernel version listThese are the additional Unraid releases that help establish when the major kernel transition happened: Unraid release Kernel Significance 7.2.3 6.12.54 Earlier kernel generation 7.2.4 6.12.54 No kernel change 7.3.0 6.18.29 Jump to 6.18 7.3.1 6.18.33 6.18 maintenance 7.3.2 6.18.38 6.18 maintenance 7.3.3 6.18.54 6.18 maintenance 7.3.4 6.18.58 Current release under discussion The release history suggests that 7.3.0 is the most important transition to investigate, because that was when Unraid moved from the previous 6.12 kernel generation to 6.18. However, the available release notes and NVIDIA changelogs do not prove that 7.3.0 first introduced the installation failures, or that 7.3.4 introduced a new regression. Direct evidence of Unraid NVIDIA plugin problems I also found two relevant reports and the actual driver-package repository. First, there is an Unraid bug report involving a Pascal GPU. A user with a Quadro P1000 (GP107) reported that upgrading from Unraid 7.2.4 to 7.2.5 caused NVIDIA driver 580.159.03 to stop working, preventing GPU-enabled Docker containers from starting. They reported restoring functionality by changing drivers and reinstalling 580.159.03. https://product.unraid.net/p/upgrade-to-7-2-5-breaks-nvidia-driver-v580-159-03 Second, there is a driver-selection problem reported on Unraid 7.3.2. Another user reported that the plugin failed to download 580.173.02 and attempted to download 575.64.05 when a different driver was selected. This involved a Turing T400, so it demonstrates a potential packaging or version-selection issue, but it is not itself proof of a Pascal-specific regression. https://forums.unraid.net/topic/200537-nvidia-driver-plugin-support/ Most importantly, the current package repository is: https://github.com/unraid/unraid-nvidia-driver/releases A release for kernel 6.18.58-Unraid exists and was published October 21, 2026, with 10 assets listed. I verified the release's existence, but GitHub did not expose the individual asset filenames in the retrieved page. Consequently, I cannot yet certify which 580 revisions are included in that release. as i no longer have a test sytem with nvida Left ealy seeing teh chagnes and didnt' want to be reliant on weired eol area and unraid/llimetech for a packge install for slackware and tehre system... (went debain/proxmox fully for thoeses needed peices...) so i can no longer go back form when i swithced off unriad nvdia track to what i'm runngin now and have 0 intrest and geting teh other needed data. outside that when they pushed a v7 update with kenreal they forced alot of users to the newer nvdia driver package. this borked adn broke alont of needed nvida driven dockers. the fix while at that time there was a older v580 driver down grading to v580 fixed the issue. the issue now is that a 580 driver no loger exist for the lattest kernel...

Yours, I can say, is due to the pascal card; the kernel no longer supports v580 and below... the NVIDIA drivers are kernel-specific, so when unraid moved out of the older kernels, this killed the lts nvdia run driver installer for pascal earleir in v7 nvida drivers. Per your screen shot it looks like v615 is the olders avalbe now... which done't support the pascal card... But 580 is the last known good for older pascall drivers... 10 seresies cards... (in my testing!!!) and was a issues in the past with eralier v7 unraid with the jump into higher kernel v6. so this is a cobmined isues of EOL hardware that nvida is no longer suporitn gin newer kernels and how slackware unirad kernel is made wheere we now need to use teh nvida upstream legacy built in module. (open source driver)... NVIDIA 580 is the final Linux driver branch supporting Pascal, Maxwell, and Volta GPUs. While It is not the final NVIDIA Linux driver overall, nor has NVIDIA ended kernel compatibility maintenance for the 580 branch. In fact, NVIDIA explicitly promises continued compatibility updates for new Linux kernels during the remaining support lifetime of the legacy branch. That makes the situation with Unraid particularly interesting: the problem may be the specific NVIDIA driver build being packaged, not that the Pascal architecture has already lost all Linux kernel support... https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ The kernel changes in recent Unraid releasesUnraid version Linux kernel Release date 7.2.4 6.12.54 Feb. 24, 2026 7.3.2 6.18.38 Jul. 8, 2026 7.3.3 6.18.54 Oct. 8, 2026 7.3.4 6.18.58 Oct. 22, 2026 These are kernel versions documented by Unraid, not yet a list of which NVIDIA driver builds successfully install on each release https://docs.unraid.net/category/release-notes/ https://github.com/unraid/docs/blob/main/docs/unraid-os/release-notes/7.3.4.md NVIDIA does not maintain a simple public table certifying every 580 driver revision against every Linux kernel patch release. However, its published driver changelogs identify specific compatibility fixes. These are useful for constructing a minimum-driver-version matrix. NVIDIA Linux driver Relevant kernel / installer information Evidence dates and wikis per offical downlad... 470.xx Final Kepler driver branch; older legacy support https://nvidia.custhelp.com/app/answers/detail/a_id/3142/kw/display%20flickers 535.xx Earlier driver generation; not the final Pascal branch https://www.nvidia.com/Download/processFind.aspx?ctk=0&lang=en-us&lid=1&osid=12&pfid=933&psid=120&qnfslb=01 570.xx Pre-580 driver branch https://www.nvidia.de/Download/processFind.aspx?ctk=0&lang=en&lid=9&osid=12&pfid=885&psid=106&qnfslb=01&whql 580.126.09 Improvements for compatibility with recent kernels https://www.nvidia.de/Download/processFind.aspx?ctk=0&lang=en&lid=9&osid=12&pfid=885&psid=106&qnfslb=01&whql 580.126.18 Explicit fix for a Linux 6.19 kernel-module build failure https://www.nvidia.com/Download/processFind.aspx?ctk=0&lang=en-us&lid=1&osid=12&pfid=933&psid=120&qnfslb=01 580.159.04 Explicit fix for Linux 7.1 kernel-module builds https://www.nvidia.co.uk/Download/processFind.aspx?ctk=0&lang=en-uk&lid=2&osid=12&pfid=845&psid=101&whql 580.173.02 Explicit fix for DKMS builds after installation with nvidia-installer https://www.nvidia.com/Download/processFind.aspx?ctk=0&lang=en-us&lid=1&osid=12&qnfslb=01&whql 580.178.04 Later maintenance release, August 3, 2026 https://www.nvidia.co.uk/Download/processFind.aspx?ctk=0&lang=en-uk&lid=2&osid=12&pfid=845&psid=101&whql This establishes an important pattern: 580 is still receiving maintenance, including fixes specifically intended to accommodate changing Linux kernel interfaces. It does not establish that all earlier drivers fail on every newer kernel. For example, a fix targeting kernel 6.19 does not automatically establish the minimum viable driver for Unraid's 6.18.58 kernel. But shows that unraid needs to make a 580 driver path file to continue supporting the kernela and the v580 taht supports your pacal g card... 580 was the last I've seen for 10 serres cards and quadro pascal cards... I worte a side guide back in the vgpu days as there were other driver parts needed when using vgpu legaly... telas cards and grid sytems... the issues most likley is the curent kenreal wont execut teh needed chagne per teh nvida run file... as seen in the githb project scripts used to generate teh updated pacakgeing. so I'm not suprised to see a bunch of users with older hardware starting to see the kienerla chagnes and isues due to new kenral nvdia run file won't install on... and since (in my tsting) the 580 driver was the last working for pascal this hardware will need to move to other distros for continmued lts support or replaced with newer...

https://nobaraproject.org/download.html use Steam-HTPC Console-like interface for living-room setups with big-screen TVs. be on a fedora distro with steam os items backed in. a lit bit better for os mutabaity and use in a VM...