How do you give a container on a NAS access to the GPU?

A diagnostic that saves a lot of guessing, because it separates the layers cleanly:

Run the vendor's own query tool inside the container. If it lists the card, steps 1 to 3 are fine and your problem is the application's configuration. If it reports nothing, the problem is below the application and you can stop reading its documentation.

For transcoding specifically, the equivalent is asking the media tool to list its available hardware accelerators from inside the container. Same logic: it either sees the device or it does not, and that single answer tells you which half to work on.

Doing this before changing settings turns a vague problem into a bounded one.

Four things have to be true, and they fail in this order:

1. The host has a working driver. The card being visible in a device list is not the same as a driver being loaded. Check that the kernel module is in use, and on platforms where the vendor driver is an optional install, that it is installed.

2. The device nodes are passed into the container. A container sees no hardware unless the runtime is told to give it some. This is a checkbox or a resource setting on most platforms, and on plain container runtimes it is an explicit device mapping.

3. The container has the userspace libraries. The kernel driver on the host is not enough — the application inside needs the matching userspace pieces, and their version has to be compatible with the host driver. This is the mismatch that produces "no device available" while everything looks correctly wired.

4. The application is configured to use it, and built with support for it. Many images have separate variants for hardware acceleration.

Most failures are step 3, and they present exactly like step 2.

One thing worth checking early on a storage server specifically: whether the slot the card is in shares lanes with your disk controller.

On boards with limited lanes, populating a particular slot can reduce a controller to fewer lanes or disable it entirely, and the symptom is disks disappearing rather than anything to do with the GPU.

Worth reading the board manual's lane-sharing table before deciding the card is fine where it is. It is a five-minute check and the failure it prevents is a much worse evening.

The platform-specific part, and the reason the old guides do not match: these storage platforms have changed their container layer between major versions, more than once, and GPU handling was rebuilt each time.

So a guide written for the previous generation describes a mechanism that no longer exists. Not a renamed setting — a different system underneath.

What to do about that:

• Use the current documentation and the current release's forum, and check the date on anything else. In this area, a guide more than a year old is likely to be describing a system that has been replaced.
• Look for the platform's own supported mechanism first. Most now expose GPU allocation as a first-class setting on an application, and using that is far better than hand-editing a compose file the platform will overwrite.

And expect a difference between the vendors: for one of the major GPU vendors this generally needs an add-on driver package and a container toolkit; for the other, the driver is in the kernel and it is mostly a matter of passing the render device through.