Is it possible to just separate the instalation for security fixes and firmware upgrades, if that is the main reason downgrading is now not allowed. In turn, this will allow us to downgrade firmware and install the required security fixes.
Great explanation Sam, and this makes sense from the compliance perspective. I just wanted to make sure the roll-back path was a valid option with the support team, and that I wouldn’t need to work my way to “level 5” support over several weeks to find someone technical enough to get a roll-back executed. Let’s hope the roll-backs are very few and far between and thanks again for taking the time to explain it.
Any idea when we will finally see QTS 6?
Thanks for the clarification Sam, but it would have been nice if the option to contact support for a rollback had been explained - it was not.
Not everyone is in the EU, so the cybersecurity regulation does not apply to all of your customers. I understand that its a very likely scenario in other countries in the future, so I can understand the reason behind the decision.
The response time of your Support team can leave a lot to be desired, but the only channel available is via email. In many organizations, service levels for email response is generally within 12-24 hours but when it comes to computer technical support, they offer other support channels such as voice and chat. That is not the case with QNAP. It can take 6-8 hours for an initial response if you’re lucky enough to have a problem during the week, but late in the day on Friday or on weekends, you’re out of luck. Follow-up responses after a customer responds can and do take just as long. That just is not feasible for any number of individuals. The ticket I opened on July 14th? Today, July 21st, they’ve finally decided to request access to my system through HelpDesk. Fortunately I had already managed to address the issue on my own, but they want to investigate further.
I have a feeling that as your customer base transitions to QuTS Hero 6, and starts experiencing issues, the dissatisfaction on this is going to grow.
This is ty[ical of laws made by people not involved in an industry. The inability to roll back makes people want to stick with a working firmware for a long time. Not getting the latest security fixes. If you put a firmware update on on a Friday night or weekend on a production machine and it breaks something, what are you going to say to the staff on Monday?
To be honest, I’d probably say quite a bit, and none of it complimentary!
In the power settings there is a setting for EU sleep mode. Why not link that setting to the ability to revert. Assumedly, those in the EU would be obliged to check that box. If they don’t, it is not QNAP’s problem. Alternatively, the rest of the world can pass laws requiring reversion.
Or, when you set up yhe NAS, instead of China or rest of world, add EU as a choice.
Just out of curiosity, I looked for this EU sleep mode - I don’t see it in the power settings for QuTS Hero. Maybe its just for QTS, or maybe my hardware doesn’t support it. Its a TS-h1887XU-RP, so it probably doesn’t support it since its a rack-mount unit.
“Control Panel”, “power” , “Eup mode” in both QTS and QuTS.
Probably means your device always uses less than 1 watt in power down mode.
TVS-AIH1688ATX upgrade from QuTS Hero h6.0.0.3500 to QuTS Hero 6.0.1.3550 without issue.
Nvidia 4000 Blackwell GPU
QXP-800S
192 GB Ram
Upgraded via control panel. I DL’ed the new OS firmware, Nvidia kernel, and Advanced Network files before I did the upgrade. Used the control panel firmware update to initiate the upgrade. Used the firmware file I had DL’ed from QNAP for the firmware upgrade. Installed without issue, then the box rebooted twice and came up with a failed Nvidia install and network adapter issues.
I now uninstalled the existing NVIDIA driver (not the kernel) and then installed the new kernel driver and the advanced network driver. Rebooted, and when the box came back up, reinstalled from the store the NVIDIA driver and rebooted again. When the box came up, everything was working. QWEN, Plex, JellyFin etc all working and using the 4000 as before.
Hello, are you making Ai with it? Because I can’t yet determine if it comes from this, but models like Gemma 4 (quantified) or Qwen3.6 (quantified, using 17GB of RAM on my RTX Pro 4000) that were loading before on the GPU can no longer do it (on Ollama).
I backtracked from Ollama to 0.30.8, the problem remains the same.
Hello,
Thank you for your response.
I had followed the approach of uninstalling Nvidia drivers, updating the kernel drivers from the QNAP site, then reinstalling the drivers.
After that, I was able to use Ollama a bit, with loads onto the GPU. But for the past few days, it’s been impossible—it only runs on the CPU (command: ollama ps), even though the card is present in the container (nvidia-smi) inside.
I have to wait until the end of a check on a hard drive that is currently in error before I can carry out maintenance tasks (uninstall the drivers again).
Additionally, I’m noticing another problem: certain parameters that should be synced internally in the OS aren’t syncing properly (this is currently preventing me from installing a new version of RClone in qpkg): QNAP - [RClone] The system volume is missing | Forum des NAS : Synology, Qnap, Asustor...
But this issue is drifting from the original subject.
Hello,
Thank you for the details. They are very useful, because they point away from the drivers.
Here is the key detail in your message: nvidia-smi sees the card inside the container, but ollama ps reports CPU. This combination means your drivers and your container runtime are working correctly. If the driver or the NVIDIA container runtime were broken, nvidia-smi would fail inside the container. It does not fail. The card is visible and correctly passed through.
What is failing is CUDA initialization when Ollama loads the model. This is a known problem, and I have it on my machine too. After the GPU has been idle for some time, CUDA initialization fails, and Ollama falls back to the CPU silently. There is no error message. The model still answers, but about 20 times slower.
Please do not wait for the disk check. You do not need to uninstall the drivers again. The fix is to restart the Ollama container only. It takes a few seconds. It does not touch your drivers, your packages, or your storage:
docker restart ollama
docker exec ollama ollama ps
After the restart, load your model and check ollama ps again. If the PROCESSOR column now shows GPU, we have the same problem, and this is your workaround. If it still shows CPU, then your problem is different, and that is important information.
Your timeline also supports this. It worked after the driver reinstall, then it degraded after a few days. A broken driver installation fails immediately and every time. It does not work correctly first and then degrade.
To prevent it, set OLLAMA_KEEP_ALIVE=24h in the Ollama container environment. This keeps the model resident in VRAM, so the idle period that triggers the failure does not happen.
One last suggestion, offered with respect. You mention a hard drive with an error and a system volume that is missing. Those are more serious than the GPU problem. I would repair the disk and the system volume first. The NVIDIA driver is installed as a QPKG package, so a damaged system volume can also affect the package system. It is difficult to diagnose the GPU while the storage layer is unhealthy.
Please tell us what ollama ps shows after the container restart.
I restarted the container several times from Container Station without success to return to optimal operation (only GPU and not CPU). Often, only restarting the NAS allowed the model to run again on the GPU.
Is it recommended/advised to manually update the “Advanced Net Driver” and “NVIDIA GPU Kernel Driver” drivers?
In any case, eventually, I am hesitating to do a NAS reset with a proper reinstallation of the firmware to resolve these cumulative issues (possibly related to using the QuTS hero 6 beta or having redone the system pool while hot running with support).
P.-S. What is your supervision system from which your images come?
achimede333,
I’m sorry you’re having issues with this. I was actually motivated to try local RAG myself because of your original posts on RAG and the 4000 Blackwell. I’m still fine-tuning Qwen, but so far the trade off is slower than I like, but private.
The dashboard I use to monitor the server is my own design. It also monitors all the containers and services as well as allowing me to manage them; start/stop/status/ignore (special use case). I don’t use container station. I build all my own Docker Compose files and bring the containers up that way.
The snapshot below has all the widgets loaded. What you can’t see is all the error reporting built into it. I’ve had memory problems with the NAS since I bought it (MCE faults) that have finally been isolated to the motherboard memory controller. It’s going in for repair tomorrow. Because of constant spontaneous reboots caused by this issue, I had to develop a way to see at a glance what was happening on the NAS. That’s how the dashboard came about, but now I use it daily to monitor the NAS and quickly isolate issues with containers, network issues, etc.
The other thing I’ve learned is that the NIC drivers for the atlantic chip used on the TVS-AIH1688ATX were handed off from alantic to Marvell and the original gitHub repo was abandoned. I don’t know who’s maintaining the drivers now, but there are issues I’ve run into that have caused at least 2 spontaneous reboots not related to the memory issues.
Rule of thumb: Don’t change NIC driver settings while anything important is happening. There has been a 50/50 chance of causing a reboot for me. Ring-resize changes will do it every time. I’ve also tracked the NIC dropping packets. If you look closely under Network, you can see my tracker at 192 dropped packets. That’s my current baseline; if it starts growing, I know my network connection needs to be bounced. Keeping the MB cooler seems to help. I’ve got my case fans running at 55% and the CPU at 50% at all times.
I keep reporting stuff as I find it, and I’m confident QNAP is working on fixing the bugs as we all report them, but it makes it challenging at times. Part of the fun of running a beta firmware. 
Yes, I had noted the fact that you had participated in the other conversation and the fact that you also have an RTX Pro 4000 made me wonder if you hadn’t jumped into it like me :).
I’m testing Ollama with Open WebUI as the interface and I switched from Gemma 4 to Qwen3.6 for testing.
It takes a long time to refine the elements, and I have many other things to manage at the same time. So the inconveniences of the pilots, they annoy me and make me waste time (and I hesitate to go over llama.cpp, but it takes even more time…, but the performance would be better).
Really nice for your interface and above all, to find the problems regarding the NAS memory…
Currently, it’s a Seagate 28T, indicating that a smart is on alert… It’s not old, I’m going to wait for the scan results, see if with the new firmware it changes anything and otherwise, RMA…
Thank you for your feedback regarding the network interface. Really bothering what you are reporting as a problem.
For now, I don’t notice any problem with my NAS, but I haven’t used all the slots for RAM (too expensive :P, and not necessary at the moment)