Informix Error -71

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning

	Value	Symbol
Catalogue text — Too many levels of remote in path	71	EREMOTE on BSD
The same condition on Linux	66	EREMOTE — Object is remote
Errno 71 on Linux	71	EPROTO — Protocol error, unrelated

python3 -c 'import os; print(71, os.strerror(71)); print(66, os.strerror(66))'

What EREMOTE Actually Tells You

A pathname lookup crossed more than one "remote" hop — the kernel refuses to chase a reference through a chain of network mounts. The classic shape: host A has a path that is itself an NFS mount of a directory on host B, and that directory on B is itself an NFS mount of something on host C. A client on A resolving all the way through to C's content is crossing two remote hops in one lookup, and traditional NFS implementations refuse it outright rather than silently chaining requests across servers on the client's behalf.

This is not a permissions problem and not a missing-file problem — the target may exist and be perfectly healthy. It is a topology problem: the path, as constructed, requires a hop the resolver won't make.

The tell: the same target is reachable in one hop from somewhere else, or after removing one layer of indirection (a symlink, an automounted map entry, a second NFS mount stacked on top of a first), but is refused when reached through the extra layer.

What This Means in Informix

Per the official text, this is an OS-level path-resolution refusal reaching the database server unexpectedly — Informix itself has no special handling for chained remote mounts, it just receives the OS's refusal like any other process would. As with -70, Informix doesn't support dbspace chunks on NFS at all, so this is far more likely to show up on a path adjacent to the instance than on the instance's own storage:

• $INFORMIXDIR (or a path it symlinks through) sitting behind chained network mounts — the same unsupported topology T<code>-70 flags, one layer worse: not just "NFS," but "NFS mounted on top of another NFS mount."
• Automounter maps that indirect through a second map, common in larger estates where a site-wide automounter delegates subtrees to per-department servers — a lookup that legitimately needs two automount expansions is exactly the shape this error refuses.
• A symlink inside one NFS mount pointing at a path on a second NFS mount — resolvable by hand in two steps, refused by the kernel in one lookup.
• Third-party backup or storage-manager software configured to stage through a path that itself sits on a remote-mounted directory one layer removed from where the software expects local storage.

Common Causes

1. A path genuinely requires two remote hops — the topology itself is the cause, not a transient fault. Nothing is broken; the request as constructed isn't one the resolver will perform.
2. Nested automounter maps, where resolving a path expands one automount entry into another automount entry rather than into a final local or single-remote target.
3. A symlink chain that crosses two different NFS mounts — each mount is fine on its own; the combination is what's refused.
4. A directory reorganization that moved a target behind an additional mount layer without anyone updating the paths that reference it, so a path that used to be one hop is now two.
5. Site-wide "convenience" mounts that re-export another server's NFS mount — re-exporting an already-mounted NFS filesystem is exactly the chained-remote shape this error exists to refuse.

Diagnostic Checks

Confirm the symbol, since errno 71 means something unrelated on Linux:

python3 -c 'import os; print(71, os.strerror(71)); print(66, os.strerror(66))'

Check the failing path's mount source, then walk upward through its parent directories if the immediate source isn't itself the second hop:

df -T /the/failing/path 2>/dev/null || stat -f -c '%T' /the/failing/path
findmnt -T /the/failing/path

List every mount in the chain, looking specifically for an NFS mount whose source is itself inside another NFS mount:

findmnt -t nfs,nfs4 -o TARGET,SOURCE

Resolve symlinks explicitly, since a symlink is often the second hop in disguise:

readlink -f /the/failing/path
namei -l /the/failing/path

Check automounter maps for nested indirection, if autofs is involved:

automount -m
cat /etc/auto.master /etc/auto.master.d/*.conf 2>/dev/null

Test whether the target is reachable with one fewer hop — directly on the second server, or via a mount taken straight from wherever the final content actually lives:

ssh <second-server> 'ls -la /the/actual/target'

Solutions / Resolution

1. Remove one layer of remoteness. Mount the final target directly on the client that needs it, rather than mounting a mount. This is the durable fix — the error exists specifically to prevent the fragile, hard-to-reason-about chained-mount topology.
2. If the extra hop comes from a symlink, repoint the symlink (or the path that uses it) at the target's real location, skipping the intermediate mount.
3. If the extra hop comes from nested automounter maps, flatten the map so the path resolves to its target in a single automount expansion.
4. Confirm $INFORMIXDIR and every dbspace chunk path resolve in at most one remote hop — ideally zero, per -70's note that NFS-hosted storage isn't a supported configuration for Informix regardless of how many hops are involved.
5. For a re-exported NFS mount, replace the re-export with a direct mount from the original server on every client that needs it, rather than mounting through the intermediate re-exporting host.

Examples

Two hops, refused

$ df -T /data/shared/archive
Filesystem                          Type
serverB:/export/shared              nfs4

$ findmnt -T /data/shared/archive/oldlogs
TARGET                    SOURCE                  FSTYPE
/data/shared/archive      serverB:/export/shared   nfs4

$ ls /data/shared/archive/oldlogs
ls: cannot access '/data/shared/archive/oldlogs': Too many levels of remote in path

serverB:/export/shared is itself an NFS re-export of a filesystem mounted from serverC — the client is one hop past what the resolver will chase.

One hop, works fine

$ mount -t nfs4 serverC:/export/archive/oldlogs /data/direct

$ ls /data/direct
2024  2025  2026

Mounting the actual source directly, rather than through serverB's re-export, resolves the same content in a single hop.

Platform Note

Platform	This condition	Errno 71 there means
Linux	errno 66, Object is remote	EPROTO — protocol error, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 71	this condition

Task	Linux	Solaris	AIX
List mounts with source	findmnt -o TARGET,SOURCE	mount -v	mount
Resolve symlink chain	readlink -f, namei -l	namei -l	namei -l
Automounter maps	/etc/auto.master, autofs	/etc/auto_master	/etc/auto_master

Related Errors / Related Topics

• -70 — Stale NFS file handle, the adjacent NFS-topology error. Both concern network-mount configurations Informix doesn't support for its own storage ($INFORMIXDIR and dbspace chunks alike); -70 is a handle going bad after the fact, -71 is a path shape refused up front.
• -2 — No such file or directory, worth ruling out first: confirm the target genuinely exists (reachable in one hop from somewhere else) before concluding the problem is topology rather than a missing file.

Where -71 appears, walk the failing path one mount at a time rather than guessing — the answer is always a second remote hop somewhere in the chain, and findmnt/namei -l finds it directly instead of by trial and error.