Informix Error -1

Operating-System Meaning

errno 1 is EPERM. The official message above, "Not owner", is the original V7/BSD wording; every current Unix and Linux renders it "Operation not permitted". The modern phrasing is the more accurate one — ownership is the usual reason, but not the only one.

The distinction from -13 (EACCES, Permission denied) matters because the two are easy to confuse and lead to different fixes:

	-13 EACCES	-1 EPERM
Means	The permission bits deny this access	The operation is not permitted to this process at all
Typical cause	Wrong mode on a file, or a directory without the search bit	Not the owner, or lacking the privilege the operation requires
Typical fix	chmod / chown on the object	Run as the right user, or grant the capability
Would chmod 777 help?	Often	No

That last row is the practical test. If loosening file modes has no effect, the error is almost certainly EPERM and the problem is who is running the operation, not what the file permits.

Operations that raise EPERM regardless of file mode include: changing a file's owner to another user, sending a signal to a process you do not own, removing a shared-memory segment owned by someone else, setting a setuid bit, raising a hard resource limit, and modifying a file with the immutable attribute set.

What This Means in Informix

Overwhelmingly the most common cause is running an Informix utility as the wrong user.

onmode, onstat, onparams, oninit, onspaces and the rest must run as the account that owns the installation. Run them as anything else and the utility cannot signal or attach to the server, and EPERM surfaces.

Which account that is depends on how Informix was installed, and this is where the usual advice misleads:

• Root installation — the owner is informix, the binaries are setuid, and root works as well.
• Non-root installation — the owner is whichever account ran the installer. On these installations there is usually no informix user on the host at all, and root has no standing over the instance either. The binaries are not setuid. The account might be ifxprod, ids, dbadmin, an application or team account, or a personal login — there is no convention to fall back on, and the name cannot be guessed.

So on a non-root installation neither informix nor root is the right account, and trying either produces the same EPERM you started with. This is the trap: the standard advice everywhere is "run it as informix or root", and on these installations both are wrong.

The corollary is that the owner has to be looked up, never assumed — and looked up per instance, since one host can carry several non-root installations owned by different accounts, each of which can only be administered by its own owner. $INFORMIXDIR is the authoritative source (see Diagnostic Checks).

Other origins:

• Signalling the server's processes — a script attempting to stop, trace, or renice oninit as a user that does not own it
• Shared memory — ipcrm against a segment owned by the installation owner, run by another account
• Chunk ownership changes — a script attempting chown on chunk files without privilege
• Raising resource limits in a startup wrapper, where a hard limit can only be raised by root
• The immutable attribute on a configuration file or chunk, often set during a hardening exercise and then forgotten
• setuid bits on Informix binaries not being restorable after a copy by a non-root user — applies to root installations only; a non-root installation has none to lose
• Container security contexts dropping the capability an operation needs, even where the UID looks correct

Common Causes

1. The utility is being run as the wrong user — by far the most frequent. On a non-root installation that includes running it as root, which confers nothing.
2. A cron or systemd job runs as root or an application account rather than as the installation owner.
3. The account is not in the installation owner's group, so it cannot interact with the server's processes or shared memory.
4. A script attempts chown/chgrp on chunks or $INFORMIXDIR contents without being root.
5. The immutable flag (chattr +i) is set on a file the engine or an administrator must modify.
6. A hard ulimit raise attempted by a non-privileged account.
7. Container capabilities dropped — IPC_LOCK, SYS_RESOURCE or similar removed by the security context.
8. Signal sent to a process owned by another account, including the case where a previous oninit was started by a different user than the one now trying to stop it.

Diagnostic Checks

Establish who the process actually is, and who it should be. On this error that is usually the whole investigation.

id
whoami
echo "$INFORMIXDIR  $INFORMIXSERVER  $ONCONFIG"

Find the installation owner rather than assuming it is informix. $INFORMIXDIR's owner is the authoritative answer, and the setuid bits tell you whether this is a root or non-root installation:

ls -ld "$INFORMIXDIR"
ls -l  "$INFORMIXDIR/bin/oninit" "$INFORMIXDIR/bin/onstat"

# root installation — owner informix, note the 's' bits
drwxrwxr-x  informix informix  /opt/informix
-rwsr-sr--  informix informix  /opt/informix/bin/oninit

# non-root installation — owner is the installing account, no setuid
drwxr-xr-x  ifxprod  ifxprod   /home/ifxprod/informix
-rwxr-xr--  ifxprod  ifxprod   /home/ifxprod/informix/bin/oninit

In the second case the correct user is ifxprod — neither informix (which may not exist on the host) nor root will do. Whatever ls -ld "$INFORMIXDIR" reports is the account to use, whatever it happens to be called.

Where a host runs more than one instance, resolve it per instance, because $INFORMIXDIR differs between them:

ps -o user,cmd -C oninit | sort -u

Find who owns the running server, and compare:

ps -o user,group,pid,cmd -C oninit
ps -ef | grep -E 'oninit|onstat' | grep -v grep

If the operation involves shared memory, check segment ownership:

ipcs -m
ipcs -m | grep -i informix
onstat -g seg

If a file is involved, check for attributes that override ordinary permissions — these are invisible to ls -l:

ls -l  /path/to/object
lsattr /path/to/object          # look for 'i' (immutable)
stat   /path/to/object

Test the operation as the intended user rather than reasoning about it:

sudo -u informix onstat - 
sudo -u informix test -w /path/to/object && echo writable || echo NOT writable

If limits are involved:

ulimit -Hn ; ulimit -Sn
sudo -u informix bash -c 'ulimit -a'
grep -n informix /etc/security/limits.conf /etc/security/limits.d/* 2>/dev/null

In a container, check the capability set rather than the UID alone:

capsh --print 2>/dev/null | head -5
grep Cap /proc/self/status

Solutions / Resolution

1. Run the operation as the installation owner, established from ls -ld "$INFORMIXDIR" rather than assumed. On a root installation that is informix, and root also works. On a non-root installation it is the installing account — which may be named anything, may be the only privileged account for that instance, and is neither informix nor root. This resolves the majority of -1 cases and should be ruled in or out first.
2. Fix the scheduling context rather than the file. A cron entry, systemd unit or container entrypoint running as the wrong account is the root cause; changing permissions to accommodate it is not a fix.
3. Add the account to the owner's group if it genuinely needs to interact with the server — and consider whether it should instead be invoking the operation as the owner.
4. Restore ownership as root where chunk or $INFORMIXDIR ownership has drifted. chown to another user is itself an EPERM operation for non-root, which is why the failing script cannot fix it.
5. Clear the immutable attribute if one is set: chattr -i /path/to/object, as root.
6. Set limits properly in /etc/security/limits.d/ rather than raising hard limits at runtime.
7. Adjust the container security context — add the required capability or set runAsUser — rather than working around it inside the container, where the change will not survive a restart.
8. Do not reach for chmod 777. It will not resolve an EPERM, and on chunks it introduces a real security problem while leaving the original fault in place.

Examples

The wrong user

$ onmode -ky
shared memory not initialized for INFORMIXSERVER 'ol_prod'
$ id
uid=1104(appsvc) gid=1104(appsvc) groups=1104(appsvc)
$ ps -o user,cmd -C oninit | head -2
USER     CMD
informix oninit -iv

The server is running and healthy; appsvc simply may not signal it. Running the same command as informix succeeds. Note that the surface message mentions shared memory, which sends people looking at the wrong thing.

Non-root installation: running as root does not help

$ id -un
root
$ onstat -
shared memory not initialized for INFORMIXSERVER 'ol_ifxprod'
$ ls -ld "$INFORMIXDIR"
drwxr-xr-x 12 ifxprod ifxprod 4096 Jul 18 14:22 /home/ifxprod/informix
$ ls -l "$INFORMIXDIR/bin/oninit"
-rwxr-xr-- 1 ifxprod ifxprod 8123456 Jul 18 14:21 /home/ifxprod/informix/bin/oninit

No setuid bit, and $INFORMIXDIR is owned by ifxprod — this is a non-root installation, so root is just another unrelated account as far as this instance is concerned. The same command as ifxprod succeeds.

This one is worth recognising quickly, because being root is normally the end of a permissions investigation rather than the cause of one, and the surface message points at shared memory instead.

Ownership drift that the script cannot repair

A rebuild script tries to correct chunk ownership and fails:

$ chown informix:informix /informix/chunks/rootdbs
chown: changing ownership of '/informix/chunks/rootdbs': Operation not permitted
$ id -un
informix
$ ls -l /informix/chunks/rootdbs
-rw-rw---- 1 root root 2147483648 Sep  2 09:14 /informix/chunks/rootdbs

Giving a file away — or taking one — is a privileged operation. informix cannot claim a file owned by root; only root can hand it over. The fix belongs in whatever ran as root and created it that way.

Permissions look right, and the file still cannot be written

$ ls -l /informix/etc/onconfig.prod
-rw-rw---- 1 informix informix 12874 Aug 30 16:02 /informix/etc/onconfig.prod
$ sudo -u informix test -w /informix/etc/onconfig.prod && echo ok || echo denied
denied
$ lsattr /informix/etc/onconfig.prod
----i--------e-- /informix/etc/onconfig.prod

The immutable bit is set — typically from a hardening pass. ls -l cannot show it, mode changes cannot override it, and only root can clear it with chattr -i.

Stale shared memory from a different owner

After an emergency restart under the wrong account:

$ ipcs -m | grep -v '^$' | head -4
key        shmid   owner     perms  bytes      nattch
0x52564801 98304   root      660    536870912  0
$ ipcrm -m 98304
ipcrm: permission denied for id (98304)
$ id -un
informix

A segment left behind by a server started as root. informix cannot remove it; root must, before the server will come up cleanly on that key.

Platform Note

errno 1 is EPERM on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number itself is reliable here. Only the wording differs: the catalogue carries the historic "Not owner", modern systems say "Operation not permitted".

What varies is the privilege model layered on top. Linux capabilities, Solaris privileges, AIX RBAC and container security contexts each decide which operations a non-root account may perform, and each will produce EPERM while file permissions look entirely correct. Confirm on the host:

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

Related Errors / Related Topics

• -13 — Permission denied (EACCES). The distinction drawn above is the important one: if changing file modes has no effect, you are looking at -1, not -13.
• -3 — No such process. Often seen alongside -1 when a script is signalling processes, one telling you the process is gone and the other that you may not signal it.
• -2 — No such file or directory.

Where -1 appears repeatedly after a migration, a hardening exercise, or a move into containers, it is usually one symptom of an ownership and privilege model that no longer matches how the estate is operated, and is better resolved at that level than case by case.