Informix Error -70

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 — Stale NFS file handle	70	ESTALE on BSD
The same condition on Linux	116	ESTALE — Stale file handle
Errno 70 on Linux	70	ECOMM — Communication error on send, STREAMS-era

python3 -c 'import os; print(70, os.strerror(70)); print(116, os.strerror(116))'

What ESTALE Actually Tells You

An NFS client is holding a file handle — an opaque reference obtained from an earlier successful lookup — that the server no longer honors. The name may still resolve perfectly well; it's the handle from before that's gone bad, typically because the server rebooted and regenerated its handle state, the export was reloaded, or the underlying file or directory was deleted and replaced rather than edited in place.

That distinction produces the signature symptom:

A process that already had the path open fails, while a brand-new lookup of the very same path succeeds.

Anyone re-running ls or cat against the failing path sees it work fine and concludes the report was wrong or transient. The path is fine. The handle a long-running process is still holding is not, and won't become valid again just because the name resolves — that process has to re-open it.

The confusable neighbor:

Error	Symbol	What it means	Fresh lookup of the same name
-2	ENOENT	The name never resolved at all	Still fails
-70	ESTALE	A handle from an earlier lookup is no longer valid	Usually succeeds

What This Means in Informix

Per the official text, Informix does not support database storage on NFS-mounted filesystems — dbspace chunks are expected to be local. This error still occurs because $INFORMIXDIR itself (the executables, $INFORMIXDIR/etc configuration, the message log, and anything else the engine reads while running) can be placed on an NFS mount by whoever installed it, and that's the configuration the official text is describing.

Where it bites, roughly in order of how surprising it is:

• Startup (oninit) or any on* utility failing to exec or read a file under $INFORMIXDIR/bin if the mount had a blip mid-read.
• $INFORMIXDIR/etc config files (onconfig, sqlhosts) becoming unreadable mid-session.
• The message log itself, if its path resolves through the affected mount — the same trap as -69's log-writability case and -30: the evidence you'd use to diagnose the problem is the thing that failed.
• A "single install, many nodes" layout, where $INFORMIXDIR is deliberately centralized on an NFS share for convenience across a cluster. This is not a supported topology, but it is a real one to find already in place.
• Third-party backup or storage-manager configuration staged on a network mount the backup agent reads at invocation time.

Common Causes

1. $INFORMIXDIR — or a path it reaches through a symlink — is on NFS at all. This is the root cause the official text calls out; everything below is a mechanism for how it surfaces, not a separate cause.
2. The NFS server rebooted or restarted its nfsd while a client held handles referencing it.
3. An automounter (autofs/amd) unmounted the path after an idle timeout and remounted it later with fresh state, invalidating handles a long-running process still held across the gap.
4. The referenced file or directory was deleted and re-created, rather than edited in place — an in-place software deploy that replaces $INFORMIXDIR's contents by renaming a new tree over the old one is a common trigger.
5. NFS server-side failover to a peer whose file-handle generation doesn't match the one the client's handle was issued against — common in HA NFS setups without carefully matched fsids.
6. The export table was reloaded or re-shared (exportfs -ra or equivalent) between the client's lookup and its later access.

Diagnostic Checks

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

python3 -c 'import os; print(70, os.strerror(70)); print(116, os.strerror(116))'

Confirm $INFORMIXDIR is not itself on a network filesystem — the configuration the official text identifies as unsupported:

readlink -f "$INFORMIXDIR"                 # follow symlinks before trusting anything below
df -T "$INFORMIXDIR" 2>/dev/null || stat -f -c '%T' "$INFORMIXDIR"
mount | grep -iE 'nfs'

Check the client's kernel log for the actual failing path — most Unixes name it:

dmesg | grep -i stale
journalctl -k --since '-1 hour' | grep -i stale

Re-resolve the same path fresh. A stale handle from an old lookup often clears the moment something looks the path up again by name — this is the check that distinguishes -70 from a path that has genuinely gone missing:

ls -la /path/that/failed
cat /path/that/failed >/dev/null

If the mount is automounted, check its idle timeout — a short one turns any pause in activity into a remount, and a remount into new handles for anything still open across it:

grep -i timeo /etc/auto.master /etc/auto.master.d/*.conf 2>/dev/null

Check the NFS server side for the event that actually invalidated the handle, since the client-side symptom alone won't distinguish a reboot from a failover from an export reload:

uptime                                      # on the NFS server, if reachable
last -x reboot | head
grep -i exportfs /var/log/messages* 2>/dev/null

Check Informix's own evidence, keeping in mind the message log itself may be what's affected:

onstat -
tail -300 "$INFORMIXDIR/tmp/online.log" 2>/dev/null || echo "log unreadable -- see mount check above"

Solutions / Resolution

1. Get $INFORMIXDIR off NFS. This is the configuration the official catalogue text identifies as the root cause, and it isn't a supported topology regardless of how reliably the NFS server behaves today. Move the install to local, or reliably local (e.g. SAN-backed, locally mounted), storage.
2. If some adjacent path must stay networked — install media, a staging area, a config-management checkout — reduce exposure to the invalidation events above: pin the automounter's timeout longer than the process's typical idle period, or mount it persistently instead of via automount.
3. Restart whatever process held the stale handle. ESTALE doesn't self-heal for a process already holding the bad handle, even once the server-side condition clears — it has to re-open the path to get a fresh one. Retrying the same open in the same process keeps failing until that happens.
4. If the NFS server was rebooted, failed over, or had its exports reloaded, treat that as the explanation rather than a mystery to keep chasing. The remaining question is whether that event was routine — in which case the affected process or script should tolerate a retry — or a genuine outage.
5. Confirm no dbspace chunk path is also on NFS. The official text's real prohibition is database storage on NFS; if an install-directory issue prompted the investigation, use the moment to also verify chunk paths are local — Informix is far more likely to silently corrupt data than to error cleanly when chunks are on NFS.

Examples

A directory that resolves fine but fails when opened

$ ls -la /opt/informix
total 8
drwxr-xr-x 12 informix informix 4096 Sep 10 09:14 .

$ tail -f /opt/informix/tmp/online.log
tail: /opt/informix/tmp/online.log: Stale file handle

The ls above succeeded — a fresh lookup by name works — but a file descriptor already open against the old handle keeps failing. That split is the tell that distinguishes -70 from a path that has genuinely gone missing.

After an NFS server event

$ dmesg | tail -4
[451202.881823] NFS: nfs4_reclaim_open_state: Lock reclaim failed!
[451203.014411] nfs: server fileserver01 not responding, still trying
[451219.662050] nfs: server fileserver01 OK

$ oninit
19236: Cannot open file /opt/informix/etc/ONCONFIG (Stale NFS file handle).

The server-side event is visible on the client's own kernel log before the Informix start-up failure — worth checking before assuming the problem is local to the database server.

Platform Note

Platform	This condition	Errno 70 there means
Linux	errno 116, Stale file handle	ECOMM — STREAMS-era, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 70	this condition

Task	Linux	Solaris	AIX
Check mount type	mount | grep nfs / findmnt -t nfs,nfs4	mount | grep nfs	mount | grep nfs
Kernel/system log for stale-handle events	dmesg, journalctl -k	dmesg, /var/adm/messages	errpt
Automounter config	/etc/auto.master, autofs	/etc/auto_master	/etc/auto_master

Related Errors / Related Topics

• -5 — I/O error, the generic device/transport failure this can be mistaken for when the underlying transport happens to be NFS. Unlike -70, -5 doesn't tend to clear on a fresh lookup of the same path.
• -2 — No such file or directory, the confusable neighbor: -2 means the name never resolved at all, while -70 means a name that did resolve earlier now has a handle the server won't honor — a fresh lookup of that same name frequently succeeds.

Where -70 appears, the first question is whether $INFORMIXDIR — or anything else the engine reads while running — is on NFS at all; that configuration is unsupported and is very often the entire explanation.