Informix Error -13

Operating-System Meaning

On Unix and Linux, errno 13 is EACCES — Permission denied. The object exists and the path to it resolves, but the requesting process is not permitted the access it asked for.

Informix is surfacing a refusal from the operating system, not applying its own privilege model. A database-level privilege failure is a different error entirely — -272 (no SELECT permission), -273, -274 and the rest of that family. If you are seeing -13, the kernel refused a file, directory, device, or IPC operation before Informix's own permission checks ever came into it.

Two distinctions decide most -13 investigations:

Check	Question	Frequently missed because
File mode	Can the installation owner read/write/execute this object?	It's the first thing everyone checks
Directory search bit	Can it traverse every directory in the path?	A missing x on a parent directory denies access to a file whose own mode is perfect
Effective user	Which account is the process actually running as?	Scripts run from cron, sudo, or a container entrypoint often are not the installation owner

What This Means in Informix

Common origins, roughly by frequency:

• Chunk and dbspace files — a cooked chunk or raw device whose ownership or mode has been changed, often by a rebuild, a patch, or a restore from backup
• $INFORMIXDIR contents — onconfig, sqlhosts, $INFORMIXDIR/etc, $INFORMIXDIR/tmp
• The message log — online.log in a directory the engine can no longer write
• Backup targets — ontape directory, onbar staging area, a tape device node
• ALARMPROGRAM and other helper scripts without the execute bit
• UDR/DataBlade shared objects the engine cannot read
• Temporary space — /tmp, DBSPACETEMP paths, sort space
• External tables reading or writing a data file as the engine's own account rather than as the connecting user
• Client-side — a sqlhosts file or TLS keystore the application account cannot read

Note the official text's mention of an attempt to execute a file that is not a program or shell script. That specific case more usually presents as -8 on modern systems; -13 is the missing-execute-bit case rather than the wrong-format case.

Common Causes

1. Ownership drift on chunks — a chunk that should be owned by the installation owner with mode 660 is owned by root after a manual operation.
2. Missing search permission on a parent directory — the file is fine, a directory above it is not.
3. The process is not running as the installation owner — a cron job, a sudo invocation, a systemd unit with the wrong User=, or a container running as an arbitrary UID. (That account is informix on a root installation and the installing account on a non-root one — establish it from ls -ld "$INFORMIXDIR" rather than assuming; see -1.)
4. Missing execute bit on a script called by ALARMPROGRAM or a backup wrapper.
5. Filesystem mounted read-only, or with noexec / nosuid.
6. NFS root squash — root is remapped to nobody on the server, so an operation that works locally fails over NFS.
7. SELinux or AppArmor denial — POSIX permissions look correct and access is still refused.
8. POSIX ACLs overriding what ls -l appears to show.
9. A restrictive umask in the installation owner's profile, so newly created files are born unreadable.
10. Lost setuid bits on Informix binaries after a copy or an archive restore that did not preserve modes.

Diagnostic Checks

Identify the object first — the message log usually names it:

tail -200 "$INFORMIXDIR/tmp/online.log"
onstat -m

Then check the object and, critically, its whole path:

ls -l  /path/to/object
ls -ld /path/to/directory
namei -l /path/to/object      # every component of the path at once
stat   /path/to/object

namei -l is the single most useful command here, because it shows the mode of every directory in the chain rather than just the target.

Confirm who the process actually is:

id ifxprod
ps -ef | grep oninit
ps -o user,group,cmd -p <pid>

Test as the real user rather than reasoning about it:

sudo -u ifxprod test -r /path/to/object && echo readable   || echo NOT readable
sudo -u ifxprod test -w /path/to/object && echo writable   || echo NOT writable
sudo -u ifxprod test -x /path/to/script && echo executable || echo NOT executable

If POSIX permissions look correct but access is still refused, look past them:

mount | grep -E 'ro,|noexec'     # read-only or noexec mounts
getfacl /path/to/object          # POSIX ACLs
ls -Z /path/to/object            # SELinux context
getenforce
ausearch -m avc -ts recent       # recent SELinux denials
dmesg | grep -i -E 'denied|apparmor'

Expected ownership for a standard installation:

ls -l  "$INFORMIXDIR"/etc/onconfig "$INFORMIXDIR"/etc/sqlhosts
ls -ld "$INFORMIXDIR"/tmp
ls -l  /path/to/chunks/*

Chunks are normally owned by the installation owner with mode 660; raw device nodes likewise.

Solutions / Resolution

1. Find the exact object and the exact operation from the message log before changing any permission. Changing modes speculatively on an Informix installation creates problems that outlive the original one.
2. Run namei -l on the full path. If a parent directory lacks the search bit for the installation owner, that is the fault, and the target file's own mode is a red herring.
3. Verify the effective user. If the failing process is a script, confirm what account it actually runs under rather than what it is supposed to run under.
4. Restore correct ownership on chunks and $INFORMIXDIR contents: ifxprod:ifxprod, 660 for chunks. Do not resort to 777 — it will mask the real fault, and on chunks it is a genuine security problem.
5. For the mount cases, remount read-write or without noexec as appropriate; a read-only filesystem under a chunk is an incident, not a permissions problem.
6. For NFS, address root squash and the export options rather than loosening file modes.
7. For SELinux, set the correct context rather than disabling enforcement.
8. Retest the specific Informix operation that failed.

Examples

The file is fine, the directory is not

$ ls -l /informix/chunks/rootdbs
-rw-rw---- 1 ifxprod ifxprod 2147483648 Sep  3 11:04 /informix/chunks/rootdbs

$ namei -l /informix/chunks/rootdbs
f: /informix/chunks/rootdbs
 drwxr-xr-x root     root     /
 drwxr-xr-x root     root     informix
 drwxr----- root     root     chunks
 -rw-rw---- informix informix rootdbs

The chunk's own mode is correct. The chunks directory is drwxr----- owned by root, so ifxprod cannot traverse it. Fixing the chunk's mode achieves nothing; the directory is the fault.

Running as the wrong user

A backup that works by hand and fails from cron:

$ sudo -u ifxprod test -w /backups/informix && echo ok || echo denied
ok
$ crontab -l -u root | grep ontape
0 2 * * * /informix/scripts/nightly_archive.sh

The script runs as root, and /backups/informix is mode 770 owned by ifxprod:ifxprod on an NFS mount with root squash — so root becomes nobody and is denied. Schedule it under the installation owner's account instead.

Missing execute bit on ALARMPROGRAM

$ grep ALARMPROGRAM "$INFORMIXDIR/etc/$ONCONFIG"
ALARMPROGRAM /informix/etc/alarmprogram.sh
$ ls -l /informix/etc/alarmprogram.sh
-rw-r--r-- 1 ifxprod ifxprod 4211 Aug 14 09:22 /informix/etc/alarmprogram.sh

Readable but not executable. chmod 750 on the script resolves it. A file that is executable but still fails here is usually -8 instead.

Permissions look right and access is still refused

$ ls -l /data/informix/chunk1
-rw-rw---- 1 ifxprod ifxprod 5368709120 Sep  9 08:12 /data/informix/chunk1
$ sudo -u ifxprod test -w /data/informix/chunk1 && echo ok || echo denied
denied
$ getenforce
Enforcing
$ ausearch -m avc -ts recent | tail -5
type=AVC ... denied { write } for pid=3122 comm="oninit"
  name="chunk1" scontext=system_u:system_r:unconfined_service_t:s0
  tcontext=unconfined_u:object_r:default_t:s0 tclass=file

POSIX permissions are correct; SELinux is refusing the write. Label the path appropriately rather than turning enforcement off.

Container running as an arbitrary UID

OpenShift assigns a random UID by default, which will not be the installation owner:

$ id
uid=1000730000(1000730000) gid=0(root) groups=0(root),1000730000
$ ls -l /opt/ibm/data/chunks
-rw-rw---- 1 ifxprod ifxprod 1073741824 Sep  9 10:02 rootdbs

The process is neither the owning user nor in the owning group. The fix belongs in the deployment — group ownership of root with group-write permission, or an explicit runAsUser in the security context — not in a chmod inside a running container, which will not survive a restart.

Platform Note

errno 13 is EACCES on Linux, AIX, Solaris, HP-UX and the BSD-derived systems; this is one of the stable low-numbered values, so the number can be relied on more than it can above -31.

What varies is the enforcement layer on top of POSIX permissions — SELinux, AppArmor, ACLs, NFS export semantics, container security contexts — and these differ substantially between platforms and distributions. When file modes look correct, the cause is almost always one of these, and checking the native errno definition will not help you. Confirm the value on the host if anything seems inconsistent:

python3 -c 'import os; print(os.strerror(13))'

Related Errors / Related Topics

• -8 — Exec format error. The object is executable and the OS cannot load its format; -13 is the missing-execute-bit or unreadable case.
• -2 — No such file or directory. Worth distinguishing: a directory without search permission can present as either, depending on where in the path the refusal occurs.
• -28 — No space left on device, the other errno that commonly interrupts chunk and backup I/O.
• -272 and neighbours — Informix's own privilege errors. If you are looking at one of those, the operating system permitted the operation and the database refused it.

Repeated -13 on chunks or $INFORMIXDIR after a restore, migration or patch is usually one symptom of a wider ownership problem across the installation, and is better resolved by verifying the whole tree than file by file.