🚨 Linux Error: Transport endpoint is not connected — Cause, Fix, and Troubleshooting Guide

Summary

Transport endpoint is not connected maps to the errno ENOTCONN (107). It means the userspace or network backend behind a mount has gone away while the mount point still exists in the namespace. The classic cause is a FUSE daemon (sshfs, s3fs, rclone) that crashed, or an NFS server that became unreachable — the kernel keeps the mount entry, but every access returns Transport endpoint is not connected because there is nothing on the other end.

Common Symptoms

• ls, cat, or stat on a mount point instantly returns Transport endpoint is not connected.
• df -h hangs or shows the mount, but the mount is unusable.
• A FUSE filesystem (sshfs/s3fs/rclone/gcsfuse) stops responding after the helper process died.
• Applications writing to the path fail immediately rather than blocking.
• umount of the dead path may itself fail with Device or resource busy.

Most Likely Causes of the ‘Transport endpoint is not connected’ Error

The Transport endpoint is not connected error means the mount’s backend disconnected. Most common in production:

1. A FUSE daemon crashed or was killed. sshfs/s3fs/rclone/gcsfuse run as a userspace process; if it dies (OOM-kill, panic, network drop), the kernel mount is orphaned and every syscall returns ENOTCONN.
2. The SSH/network session behind sshfs dropped. A transient network partition or an idle-timeout kill on the remote sftp-server leaves the mount dead.
3. An NFS server went away and the mount was soft-mounted or otherwise gave up the connection, so the endpoint is reported disconnected rather than hanging.
4. The backing service restarted (object-store credentials rotated, S3 endpoint changed) and the FUSE process exited instead of reconnecting.
5. OOM killer reaped the FUSE helper on a memory-pressured host, silently killing the mount.

Quick Triage

# Confirm the dead mount without touching its contents
findmnt /mnt/remote
# Is the FUSE/backend process still alive?
pgrep -a -f 'sshfs|s3fs|rclone|gcsfuse'
# Any oom-kill or fuse errors in the log?
dmesg | tail -20

If findmnt shows the mount but the FUSE process is gone, the endpoint is dead and must be unmounted.

Diagnostic Commands

# Show the mount type and source (fuse.sshfs, nfs4, etc.)
findmnt /mnt/remote
mount | grep /mnt/remote
cat /proc/mounts | grep /mnt/remote

findmnt tells you whether it is FUSE (fuse.sshfs, fuse.s3fs) or NFS (nfs/nfs4) — the remediation differs slightly.

# Is the backing userspace daemon still running?
pgrep -a -f 'sshfs|s3fs|rclone|gcsfuse'
# Kernel evidence: OOM kills, FUSE/NFS transport errors
dmesg -T | grep -Ei 'fuse|nfs|oom|killed process' | tail

# For NFS mounts: is the server reachable and exporting?
showmount -e <nfs-server>
nfsstat -m
ping -c2 <nfs-server>

If showmount -e fails or times out, the NFS server or network is the root cause; if the FUSE process is simply missing from pgrep, the daemon crashed.

Fix / Remediation

1. Confirm the backend is dead, then unmount the orphaned mount point:

   pgrep -a -f 'sshfs|s3fs|rclone'
   sudo umount /mnt/remote

2. If a normal unmount fails with the mount busy or not connected, use FUSE’s own unmounter or a lazy unmount:

   sudo fusermount -uz /mnt/remote     # FUSE mounts
   sudo umount -l /mnt/remote          # lazy detach, any type

   Warning: umount -f/umount -l on a mount with unflushed writes can lose in-flight data. For a FUSE mount whose daemon is already dead, the buffers are gone regardless — but for a merely-slow NFS server, try to restore connectivity and flush before forcing.

3. Remount cleanly once the mount point is free and the backend is reachable again:

   # sshfs example
   sshfs user@host:/data /mnt/remote -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3
   # NFS example
   sudo mount -t nfs4 <server>:/export /mnt/remote

4. For NFS, fix the server/network first. Restore the export and connectivity (showmount -e succeeds), then remount with hard and a sane timeo.

Validation

# Mount point responds again
ls -la /mnt/remote && echo "mount healthy"
# Backend daemon is running (FUSE)
pgrep -a -f 'sshfs|s3fs|rclone' || echo "no fuse daemon"
findmnt /mnt/remote

A healthy mount lists its contents instantly with no ENOTCONN.

Prevention

• Mount sshfs with -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 so dropped sessions re-establish automatically.
• Run FUSE mounts under a systemd unit with Restart=on-failure so a crashed daemon is respawned and remounted.
• For NFS, prefer hard mounts with a bounded timeo/retrans so a slow server retries rather than orphaning the mount.
• Add memory limits/reservations so the OOM killer does not reap FUSE helpers on busy hosts.
• Alert on mount health (a periodic stat probe) to catch a dead endpoint before applications do.

Related Errors

• Stale file handle
• Input/output error
• Device or resource busy
• mount: wrong fs type, bad option, bad superblock

Final Notes

Transport endpoint is not connected is a dead-backend problem, not disk corruption: the kernel is holding a mount whose FUSE daemon or NFS server has vanished. Confirm the backend is really gone, unmount with fusermount -uz or umount -l, fix the underlying process or server, then remount with reconnect/hard options so it self-heals next time.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.