Informix Error -115

Reasons / Common Causes

-115 is an OS-level failure, not a logic error: on operating systems where ISAM implements locking through a tablename.lok file (the same mechanism -113 can report as already locked), the processor tried to create that file and the OS refused. The official text points straight at the two most common reasons — a full disk or a permissions problem — but the full range of OS-level causes is worth knowing:

1. The filesystem is full in the directory where the .lok file needs to be created — even a tiny lock file can't be created with zero free space available.
2. Insufficient permissions for the account running the Informix engine or the C-ISAM program in the relevant directory — often introduced by an unrelated change: a backup/restore that reset ownership, a permissions audit, or an OS/filesystem migration.
3. The target directory doesn't exist or was moved/renamed — a dbspace or chunk path that drifted out of sync with configuration, or a broken symlink.
4. The filesystem is mounted read-only, unexpectedly — after a failed or incomplete remount, an NFS mount issue, or the filesystem itself detecting corruption and remounting read-only as a protective measure.
5. A filesystem quota was exceeded — distinct from raw disk-space exhaustion; a per-user or per-group quota on the specific filesystem can block file creation even when df shows free blocks.
6. Inode exhaustion — the filesystem has run out of inodes even though block space remains available; this produces the same practical symptom (can't create a new file) as a full disk, but needs a different check to detect.
7. A mandatory access control policy (SELinux, AppArmor) blocking the create operation despite normal Unix permissions appearing correct — common after a security policy update or a context/label mismatch following a file move.

Solutions / Resolution

1. Check available disk space in the target directory's filesystem and free up space if it's full — the most common cause by a wide margin.
2. Verify and correct permissions for the account running the engine or program in the relevant directory — confirm ownership and mode match what's expected, especially after any recent restore, migration, or permissions audit.
3. Confirm the target directory actually exists and matches current dbspace/chunk configuration — fix any path drift.
4. Check filesystem mount status and remount read-write if it unexpectedly went read-only — then investigate why it went read-only, since that's usually a symptom of an underlying disk or filesystem problem worth addressing on its own.
5. Check filesystem quotas separately from raw usage if disk space appears available but creation still fails.
6. Check inode usage in addition to block usage — a filesystem can report free space while being completely out of inodes.
7. Check SELinux/AppArmor denial logs if a mandatory access control system is in use and normal permissions look correct.
8. Read the accompanying OS-level error message — per the official guidance, this is usually the fastest path to the specific cause, since the underlying OS error (ENOSPC, EACCES, EROFS, etc.) typically names the exact problem directly rather than leaving it to inference.

Examples

Disk full

$ df -h /informix/dbspace
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        50G   50G     0 100% /informix/dbspace

No amount of retrying the ISAM operation helps until space is freed — the lock file genuinely cannot be created with zero bytes available.

Inode exhaustion despite free block space

$ df -h /informix/dbspace
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        50G   30G   20G  60% /informix/dbspace

$ df -i /informix/dbspace
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sdb1     3276800 3276800      0  100% /informix/dbspace

df -h alone would suggest plenty of room; the inode count tells the real story — a directory with an enormous number of small files can exhaust inodes long before it exhausts blocks.

Permissions broken by a restore

$ ls -la /informix/dbspace/customer.lok 2>&1
ls: cannot access '/informix/dbspace/customer.lok': Permission denied

$ ls -ld /informix/dbspace
drwxr-x--- 2 root root 4096 Sep 20 10:00 /informix/dbspace
# should be owned by the informix service account, not root

A restore or migration that didn't preserve the original ownership is a common way for this to appear well after the engine has otherwise been running fine.

Diagnostic Checks

1. Check disk space and inode usage together:

   df -h /informix/dbspace
   df -i /informix/dbspace
   

2. Check directory ownership and permissions:

   ls -ld /informix/dbspace
   

3. Check for an unexpected read-only mount:

   mount | grep /informix
   

4. Check OS logs for filesystem errors around the failure time:

   dmesg -T | grep -iE "error|read-only|remount"
   

5. Check SELinux/AppArmor denials if applicable:

   ausearch -m avc -ts recent
   

6. Read the specific OS error accompanying -115 in the application or engine's own error output — it usually names the exact syscall failure (ENOSPC, EACCES, EROFS, EDQUOT) directly.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -113 — "ISAM error: the file is locked." The two share the same tablename.lok mechanism on operating systems that implement ISAM locking through files: -113 means the lock file exists and something else holds it; -115 means the lock file couldn't even be created due to an OS-level problem. Different failure, same underlying mechanism.

Don't treat -115 as an application logic problem — it's always an OS-level condition (space, permissions, mount state, or a security policy), and the accompanying OS error message is normally the fastest route to the specific cause.