Mounting remote storage fails with a fatal error about not being able to mount the FUSE filesystem

It matters a great deal, and it is almost certainly the whole answer.

Mounting is a completely different operation from copying. The transfer commands are ordinary network calls — they need credentials and nothing else, which is why they work. Mounting asks the kernel to present a filesystem, and that needs a kernel facility and the privilege to use it. In a container, neither is available by default.

What a container needs to mount a FUSE filesystem:

1. Access to the FUSE device. The container must be given the /dev/fuse device node. Without it the helper cannot talk to the kernel at all.
2. The privilege to mount. The mount capability is dropped from containers by default. You need to add it back, or — better — grant the specific capability rather than running the container fully privileged. SYS_ADMIN is the one usually required, and it is broad, so scope it to the one container that needs it and nothing else.
3. An appropriate security profile. Default sandboxing profiles block the mount system call. Depending on your runtime you may need to relax that for this container.
4. The FUSE user-space helper installed inside the image. The mounting binary shells out to a helper. If the image does not contain it, you get a fatal error that reads like a mount failure but is really a missing executable — the message often names the helper, so read the full error rather than the first line.

That fourth one is the most common on slim images and the easiest to fix.

Then, to make the mount visible outside the container, which is usually the actual goal: by default a mount inside a container is confined to that container's mount namespace, so other containers and the host see nothing at that path. You need the volume to be shared with mount propagation enabled — a bind mount marked as shared or rshared — so the mount event propagates back out. Without it, everything succeeds and the directory looks empty from everywhere else, which is a very confusing place to end up.

Two more that catch people even outside containers:

• Allowing other users. If another service under a different user needs to read the mount, the option permitting that requires a line to be enabled in the FUSE configuration file. Without it the option is rejected outright.
• Startup ordering. If you mount from a service at boot, it must start after the network is genuinely up, and anything that depends on the mount must start after the mount. Getting this wrong produces a service that works when you start it by hand and fails after a reboot — and then works when you check, because you started it by hand again.

One design note worth having before you invest in this. A network storage mount is not a local disk and behaves badly when treated like one: metadata operations are slow, random writes are expensive, and any application that expects a real filesystem — a database, an application that writes in place, anything using file locking — will be unhappy or unsafe on it.

For bulk sequential reads it is fine and genuinely useful. For anything else, syncing to local storage and working there is usually the better arrangement.

The mount propagation point deserves emphasis because the symptom is so misleading.

Everything reports success. The container's logs are clean. You look at the directory from the host or from another container and it is empty, so you assume the mount silently failed and go back to debugging credentials.

Quick check: get a shell inside the container doing the mounting and list the directory there. If the files are visible inside and not outside, it is propagation and nothing else, and you can stop looking at everything upstream of it.

That one test saves a lot of time and it is the first thing I do now.

On the design note: do not point a backup program at a mounted remote as if it were a local disk.

Backup tools that expect a real filesystem will do a large number of small operations, and over a network mount that is slow enough to turn a nightly job into a permanent one — and the failure modes on interruption are worse, because a partial write to a remote through a mount is not the same as a partial write to a disk.

Most of these tools can talk to remote storage directly as a backend, without any mount at all. That path is designed for it, handles retries, and is dramatically faster. If you are mounting purely so a backup tool can see the storage, check whether it supports the backend natively first.

If you can avoid needing the elevated capability at all, do. Granting broad privileges to a container to satisfy one mount is the kind of thing that is fine until the container runs something you did not expect.

Two alternatives worth a look: mount on the host and bind the resulting directory into containers as an ordinary volume, or use a service that presents the remote over a network protocol the consumers already speak. Both keep the privilege out of the containers.

The host mount is the one I would try first — one privileged thing, in one place, that you configured deliberately.