Upgrade outdated glibc (currently 2.21) in upcoming QTS 5.2.x releases

Feature Request
1

Hi QNAP Team and Community,

I would like to request an update to the core GNU C Library glibc in upcoming QTS 5.2.x firmware releases.

Currently, the firmware still relies on glibc 2.21, which dates back to 2015. This severely limits compatibility with modern software builds and community packages. Specifically, updating to a more recent version (such as glibc 2.41 from 2025, or another modern release) would allow users to run newer tools and packages natively, such as Silas Z’s rtorrent16, without running into missing symbol errors or library incompatibility issues.

Bringing core toolchains up to date would significantly improve third-party package support, performance, and overall system longevity.

Is an update to glibc planned for the QTS 5.2.x cycle? Any insights or roadmap updates would be greatly appreciated.

Thank you!

1 Like
2

Every ticket I’ve opened with support for the last year has included this request. I’m glad you posted it. This is even more important now with AI agents roaming the net looking for vulnerabilities.

1 Like
3

Honestly, the forward path is QTS/QuTS 6. I don’t believe QNAP is doing updates (other than perhaps a security update here or there) to QTS 4 any longer. There comes a time when updating a part of an OS is not worth the effort when a newer version exists. Machines that don’t support version 6 will eventually go EOL. That doesn’t mean that they are not going to be supported by tech support with operating questions or stop working. It means there’s no more software updates, etc. People here are regularly talking about NAS units they have that are 20 years old. Those certainly are not getting any updates.

A QNAP NAS should pretty much never (but for rare circumstances) be directly exposed to the internet. Too many people have learned this the hard way. So the AI agents roaming looking for vulnerabilities shouldn’t even see your NAS.

Also, while QNAP supports models through tech support that were obsoleted years ago, that’s an amazing thing. The fact they support so many out of production models and continue to provide software updates is amazing. But this costs them. The main source of revenue is selling new hardware. To put it bluntly - not supporting older NAS units with the new software version, allows them to collect revenue from people who have those older units who now want to buy a new one to stay with the latest feature set. If they supported everything for ever, they would sell far fewer NAS units and have much more bloated and complicated software supporting all the old chipsets, memory, etc…

4

Correct, the last QTS 4 updates were released in December 2024.

I don’t expect we’ll see any further updates for QTS 4. :nerd_face:

1 Like
5

@NA9D Thanks for the reply. I agree a NAS shouldn’t sit directly on the internet, and for a home media box that’s often enough. My problem is that the forward path (QTS/QuTS 6) doesn’t actually fix what I’m dealing with.

I have a support ticket open for months on ZFS ARC fragmentation caused by its interaction with the NVIDIA display driver. A fix that “might work” landed in the new 6.1 branch. When I looked at that release, it’s shipping a driver that’s already a year out of date. Here’s the relevant part of the ticket:

Can I downgrade from the 6.1 beta back to 6.0.2.3656?

QNAP’s NVIDIA driver track record is my concern:

Driver Released Notes
QNAP GPU Driver 5.2.0.0621 2024-10-28 Built on NVIDIA 550.67, two major branches old at release
QNAP GPU Driver 6.2.3.0580 (6.1 beta) Now Built on NVIDIA 580.x (per version stamp), ~1 year old, with a known list of bugs and CVEs
NVIDIA GPU Driver 595.99 (production branch) Aug 2026 Current
NVIDIA GPU Driver 615.78.08 (feature branch) Oct 2026 Current

My box is stable on current firmware as long as I reboot before memory fragmentation gets too bad. I built a monitor that emails me when it’s time. Today, after 72 hours of uptime, I’m down to 8% contiguous memory scattered across >256K blocks. AI stacks need a few contiguous 512K or larger blocks to load into VRAM; without them the load fails and the box goes unstable until a reboot. So I now reboot preemptively.

Bigger picture: BusyBox is ancient, NVIDIA drivers are years behind, and AI is coming for every code stack in existence. An incremental approach would help: bring the NVIDIA and Intel video drivers current, patch whatever that breaks in the OS, then commit to maintaining those updates before moving on. Something has to be done, and soon.

If there’s a way back from the 6.1 beta, I’ll try it. Otherwise I’m wary of trading a delicately balanced but workable setup for days of downtime chasing a new set of bugs from a newly released, year-old driver.

On exposure: the fragmentation problem is a local stability issue and has nothing to do with internet exposure. But since the “AI agents” point invites the question, here’s my view. A server exists to serve clients. In production that means reachable services: reverse proxies, VPN endpoints, shares, APIs, container workloads. A home media server can reasonably stay behind the firewall, but a production environment can’t. Even where the perimeter is well controlled, the host OS is the last line of defense. Once any client, credential, or container is compromised, an ancient glibc, BusyBox, and driver stack is what an attacker, or an automated agent, gets to work against. Perimeter-only security is a single point of failure.

This same lack of current drivers is behind most of the workarounds I’ve had to build just to make this NAS usable. Every boot, an autorun script assembles a toolbox: current BusyBox, current glibc, and more. I shouldn’t have to do this kind of remediation on a box I bought 8 months ago for $20K. Some customization is expected with any server OS, but when firmware ships with years-old drivers, I have to question the decisions being made at the corporate level.

6

First, I don’t think QuTS Hero 6.x runs BusyBox (I think @Silas mentioned in a post somewhere that it’s built on Debian). There’s far more in the Linux OS than what BusyBox provides. Deploying stable Linux kernels for long term use is a challenging endeavor. Sometimes not updating packages results in better security. There was one a couple months ago (not the recent PHP thing) where most of the QNAP releases that were in the wild were not affected by the bug because the bug was introduced in releases later than were being used by QNAP.

Additionally, changing the drivers in a product where the long term goal is stability is not always that straightforward. Yes, we want to have drivers updated in newer releases of the OS and it should be. Development of QuTS 6.1 probably began over a year ago and what was included were the drivers available then. In development of a new release like this that introduces some major improvements and changes, it’s better to freeze the drivers and get the OS stable and put out to beta and released. Then come along with driver updates.

I’m not interested in starting an argument about timelines and whether or not QNAP should have included a newer driver for Nvidia in 6.1. Maybe they should have. I don’t know. My statements above are guesses as I have no knowledge of QNAP development timelines. But before I retired I sold microprocessors that ran Linux and changing drivers in Linux is no easy task. I learned a lot about that.

My comments are more about the fact that the OP is asking for QNAP to provide new libraries to an OLD operating system. That I don’t think is going to happen and at some point it has to stop happening.

2 Likes
7

Yes @na9d have right

@Augustinus

Topic is interesting but im afraid time to say goodbye longtime for old glibc

But here are some tools that might help you digging this

Bucket & Code Server IDE · the workshop for QNAP servers

Claude Code, Gemini CLI and Codex CLI on your NAS · How-to’s

8

Thanks for getting back to me on this.

I’m seriously considering a NUC instead of buying another QNAP.

My TS-253D has 16 GB of RAM and is running perfectly.

Just because QNAP refuses to update their firmware with the latest libraries, they expect me to upgrade my hardware… Absolutely not. Not going to happen

9

So @Augustinus - Is the current software on the NAS preventing you from anything? Yes, you can’t use Rtorrent just like on an old PC running Windows 8, you probably can’t run a Windows 11 software package. This happens all the time.

So if your old QNAP is running fine, then fine. But I doubt a NUC is going to give you the integration and capabilities of a QNAP. NUCs are small form factor and certainly don’t have the capability of having an array of drives in RAID configuration. But hey - that’s your call.

You say your TS-253D is running perfectly so what is your complaint? It’s very likely your older NAS is not capable of running all the latest software in QTS 6. There has to come a time when companies drop support for old hardware.

10

Buying a NUC makes sense.

I always say that if you are able to build your own server and set up your NAS from scratch, something went wrong in your life. You should be a millionaire instead of wasting your time setting up all these things. I’m probably the best example of this. :joy:

But let’s do the math.

The TS-253D was released ONLY 6 years ago (almost 7 now). Its price includes many things: distribution, compatibility testing, small details, community, marketing, RMA, and technical support.

On the other hand, I absolutely understand your point of view. Prices today are insane, IMHO.

However, I can’t imagine manually creating Samba shares and writing configuration files for everything (maybe it’s because I’m getting old). I simply believe that time is priceless.

But the world is changing…

Today, you can ask AI to build your own “QNAP” for you. And I’ve been thinking about this for a while. It actually makes sense.

So let’s put both on the same timeline and see where you end up:

  • Your empty NUC, starting from scratch
  • Your ready-to-use QNAP, where you just click, click, and you’re done

Of course, everything depends on your environment and requirements.

Anyway, here’s another interesting question.

Could this have something to do with the European Union’s Cyber Resilience Act (CRA)?

Maybe QNAP has to be careful about releasing new firmware for older devices because of these security regulations?

For example, if QNAP releases a new firmware version for a 6-year-old NAS, could that mean they would have to provide security updates for another 5 years?

I’m not sure how this law works in practice, but perhaps it’s worth asking AI to do some research. Maybe there’s more to this story than we think. :slight_smile:

In the meantime, I’d simply ask you to think once again about what really works best for your needs.

Because at the end of the day, hardware has a price, software has a price, but your time has a price too. And that’s something we often forget.

1 Like
11

CRA is a huge impact. That’s why you can’t downgrade after upgrading to 6. And attempting to upgrade all the libraries, etc. and make an old machine CRA compliant, might be a huge lift.

12

Thanks for raising this. Our team is actively working on bringing QTS 6.1 to the TS-253D, which would resolve the compatibility issues you’re running into with the older glibc. While we can’t guarantee the outcome just yet, we’re doing our best to make it happen. Thanks!