Informix Error -125: ISAM error: can't use nfs.

Reasons / Common Causes

-125 is a hard architectural constraint, not a transient or configurable condition: database files cannot live on NFS-mounted storage. The ISAM processor requires disks physically attached to the machine it's running on (including SAN/iSCSI storage that presents as local block devices) — genuine network-filesystem access to the underlying files isn't supported at all.

1. Database files placed directly on an NFS mount, often for convenience during a storage setup that didn't account for this restriction — a shared-storage arrangement that seemed like a reasonable way to centralize data files.
2. Confusing NFS with SAN/iSCSI. Both are "network storage" in a loose sense, but SAN/iSCSI presents as a local block device to the operating system and is fine for database files; NFS is a network filesystem protocol and is specifically what this restriction targets. Mixing the two up during storage planning is an easy, common mistake.
3. Attempting cross-machine database access by NFS-mounting another machine's data directory, instead of using actual client/server database connectivity. The official text is explicit that the correct mechanism for accessing a database on a different computer is networking software (Informix STAR/NET historically, or standard client/server connections in current terms) talking to a database server process — not sharing the raw files over a network filesystem.
4. Container or cloud storage that's secretly NFS-backed. Some persistent volume types in cloud or container platforms present as an ordinary mounted filesystem but are implemented as NFS underneath — a subtler version of cause #1, where the choice to use NFS wasn't made explicitly or knowingly.
5. A previously working setup breaking after an infrastructure change — a storage migration or a change in what technology backs a "shared storage" mount can turn a previously local/SAN-backed path into an NFS one without anything in the application changing.

Solutions / Resolution

1. Move database files onto genuinely local, or SAN/iSCSI-presented-as-local, storage. This is the only real fix — there's no supported configuration that makes NFS-hosted database files work.
2. For legitimate cross-machine access, use actual client/server database connectivity — connect to a database server process running where the disks physically are, rather than trying to share the underlying files through a network filesystem.
3. When provisioning storage for a new deployment, verify explicitly whether a "shared storage" option is NFS-based or block-based before putting dbspaces on it — don't assume all network storage options are equivalent.
4. For container/cloud environments, check the actual backing technology of any persistent volume before mounting database dbspaces on it — confirm it's block storage, not an NFS export presented as a filesystem.
5. If a previously working setup suddenly hits this, investigate what changed in the storage layer — an infrastructure team's substrate change or a volume-type switch is the likely trigger, not anything in the application or database configuration itself.

Examples

The straightforward NFS mount

$ mount | grep dbspace
nfs-server:/export/dbdata on /informix/dbspace type nfs (rw,...)

If the directory hosting a dbspace chunk shows type nfs, that's the entire diagnosis — no amount of ISAM-level configuration works around this; the data needs to move to local or SAN/iSCSI storage.

The cloud volume that's secretly NFS-backed

$ mount | grep dbspace
10.0.1.5:/vol1/dbdata on /informix/dbspace type nfs4 (rw,...)

A managed "file storage" or "shared volume" offering in a cloud platform can be NFS underneath even when it wasn't chosen with that in mind — checking the actual mount type is the only way to be sure.

Confusing SAN with NFS during planning

A storage team provisions "network storage" for a new database server, intending an iSCSI LUN (which would have been fine, presenting as a local block device), but an NFS export gets attached instead due to a miscommunication. The database deployment fails with -125 the moment it tries to use it — the fix is provisioning the correct storage type, not anything in the database configuration.

Diagnostic Checks

1. Check the mount type of the directory hosting the affected dbspace chunk:

   df -T /informix/dbspace
   mount | grep /informix/dbspace
   

   nfs/nfs4 in the output confirms the cause directly.
2. Review recent infrastructure or storage changes if this appeared unexpectedly on a previously working setup.
3. For cloud/container deployments, check the actual backing technology of the persistent volume in use — consult the platform's documentation for the specific volume type, since the mount itself may not obviously announce it.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -115 — "ISAM error: cannot create lock file." Also a storage-arrangement problem, though a different one — -115 is an OS-level permissions/space failure on otherwise-valid storage; -125 is a fundamental incompatibility with the storage type itself, regardless of permissions or space.

There's no configuration flag or workaround for -125 — confirm the storage type first, and treat moving off NFS as the only real fix.