Fahri

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.

Add alerting on this before you fix it, because the pattern you describe — one direction failing quietly on a schedule — is the failure mode that goes unnoticed for months.

If your sync is a scheduled job, make a failed run notify you. A backup that has been silently failing since March is worse than no backup, because you believe you have one.

And separately from alerting: verify the far end has what you think it has. Check the file count and a recent file's timestamp on the remote, not just that the job reported success. The two are not the same claim.