Nihat

One symptom worth separating from the driver question, because it looks identical and is not: a link that comes up and then drops under sustained transfer.

If the driver is loaded and the interface links at the expected speed, but large transfers stall or the link resets, look at cabling and heat before rebuilding anything. These controllers run warm, and 2.5 gigabit is much less tolerant of marginal cable than gigabit is — a run that was fine at the lower speed can fail at the higher one.

Forcing the link to gigabit is a good diagnostic. If everything is stable at the lower speed, the driver is fine and you have a physical problem.

On timing, and this is the part I would weigh most: do not migrate onto a major platform release on the day it arrives.

The replacement arriving in the next release means the integration is new. New integrations on storage platforms have rough edges, and the people who find them are the ones who upgraded immediately.

What I would do: keep the existing environments running on the version you are on, which still works, and set up one new container on the new release to learn the tool and validate the id mapping. Move the rest when the release has had a point update or two.

The old tool being unmaintained is a reason to plan the move, not a reason to do it this week. Unmaintained is not the same as broken, and it will keep working exactly as well as it did yesterday.

What went wrong is a distinction that catches everybody once: the setting points at where the application will look, and changing it does not move anything.

So you now have an application pointed at an empty location, and your data sitting in the old one. Nothing is lost and nothing is linked.

The order that works:

1. Stop the application. Moving data underneath a running application is how you get a half-copied library and a database that references files that are being moved.
2. Move or copy the data to the new location, preserving ownership and permissions. Copy rather than move if you have the space — then a mistake is recoverable.
3. Check ownership at the destination. This is the usual reason it still fails after a correct move: the application runs as a specific user id, and the new location is owned by something else.
4. Point the setting at the new location.
5. Start it and verify before deleting anything from the old location.

Step 5 is not optional. Keep the old copy until you have confirmed the application sees everything.

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.

Worth confirming what the system is seeing before buying anything, because it takes a minute and it tells you whether the enclosure is the culprit:

lsblk -o NAME,SERIAL,WWN,TRAN,SIZE

Look at the transport column and the serial. If everything on usb shows an empty or identical serial while anything on sata shows a real one, you have your answer directly.

The WWN column is worth noting too — it is another stable identifier, and a bridge that drops the serial sometimes drops that as well. A drive with neither is invisible to any sane identity scheme.