Informix Error -30

Operating-System Meaning

errno 30 is EROFS — Read-only file system. A write was attempted on a filesystem mounted read-only.

The official text is right that an entire filesystem has been made read-only, and right to say the administrator should find out why. That "why" has two entirely different answers, and they are not equally benign:

	Someone chose it	The kernel imposed it
Cause	Mounted ro in fstab, by hand, an ro NFS export, a snapshot, a read-only container volume	The filesystem hit an error and protected itself
Severity	Configuration	Possible data corruption or failing storage
Where the evidence is	mount, fstab, the export	dmesg — a remount message with a reason above it
Safe to remount read-write?	Usually	No — not until you know what happened

Most journalling filesystems default to protecting themselves this way. On ext-family filesystems the errors=remount-ro behaviour is the default: on detecting metadata corruption or an I/O failure, the kernel stops accepting writes rather than compounding the damage.

On a database server, assume the second case until you have proved the first. A filesystem that turned itself read-only did so because continuing looked worse than stopping. Remounting it read-write and carrying on discards that protection, and if the cause was corruption or a failing device, the damage that follows is yours rather than the kernel's.

What This Means in Informix

A read-only chunk filesystem is not a degraded mode the engine runs in. It is incompatible with running at all.

This is worth stating plainly, because "read-only" sounds survivable for a read-mostly workload and is not. Informix writes continuously regardless of what applications are doing:

• The reserved pages, which live in the root dbspace and hold the instance's own control information. These are updated as a matter of course, not only when user data changes — so a read-only root dbspace stops the instance regardless of what any application is doing.
• Chunk header pages. Every chunk, in every dbspace, carries its own header pages describing that chunk. These are a separate structure from the reserved pages and exist on each chunk rather than only in rootdbs.
• Checkpoints, which write whether or not anyone is running a SELECT.
• The physical and logical logs.
• The message log, and anything under $INFORMIXDIR/tmp.

That distinction matters when only part of the storage has gone read-only: a filesystem holding the root dbspace is fatal immediately, while one holding other chunks fails at whatever next needs to write there.

So the timing determines what you see, and the two cases look quite different:

Read-only before the instance starts

Startup fails, and it fails early — the engine updates reserved pages as part of bringing the instance up, so the failure lands close to the point where it tries to write the root chunk rather than after any recovery work.

This is the more common presentation, because the usual sequence is: a fault occurs overnight, the filesystem goes read-only, the instance stops or is stopped, and the failure everyone sees is a server that will not come back.

Read-only while the instance is running

There is a useful asymmetry here that narrows the investigation considerably.

Nobody can quietly flip the mount to read-only under a running engine. mount -o remount,ro is the only interface to the mount flags, and it is refused with EBUSY while anything holds a file open for writing — which a running instance does, for every chunk:

# mount: /informix/chunks: mount point is busy

The kernel's own protective remount does not go through that check. When errors=remount-ro fires, the filesystem goes read-only regardless of what has it open, and so does the u sysrq.

Write access can still be taken away from beneath the filesystem, without the mount being touched at all:

Route	Effect
blockdev --setro on the underlying device	Succeeds while mounted. The block layer starts rejecting writes
A device-mapper table reloaded read-only or onto an error target	Mapping swapped underneath; the filesystem is not consulted
An NFS export changed to ro on the server	Client writes fail immediately; no client-side remount occurs
A LUN presented read-only, or a failover path that came up read-only	Writes rejected at the array

This matters more than it first appears, because in all of those cases findmnt and /proc/mounts still report rw — until the filesystem hits enough errors to remount itself. A mount line that looks healthy does not clear this error, and it is the single most common reason an investigation stalls here.

So the practical rule is: a person did not change the mount, but a person may well have changed something below it. Check the kernel log and the storage layer, not the fstab.

Writes then begin failing wherever the engine touches that filesystem. What the engine does next — assert failure, marking objects down, shutting the instance down — depends on which filesystem it was and on the version, and is worth observing in your message log rather than assuming. If the affected filesystem holds the root dbspace, expect the instance to stop rather than continue in some reduced state.

One consequence is reliable whichever way it goes: the message log may itself be unwritable, so the evidence you would normally reach for inside Informix may simply not have been recorded. That makes the kernel log the primary source on this error — the same as -5, and for related reasons.

Common Causes

1. The kernel remounted the filesystem read-only after an I/O error or metadata corruption. Treat as the default assumption.
2. Mounted read-only deliberately — an fstab entry, a manual mount, or a recovery boot nobody undid.
3. An NFS export that is read-only, or exported read-write to a different client than the one mounting it.
4. A snapshot or clone mounted where the live filesystem was expected.
5. The device itself is write-protected — a LUN presented read-only, a failed-over replica, or a hardware switch.
6. A container with a read-only root filesystem or a volume mounted ro.
7. A storage failover where the new path came up read-only.

Diagnostic Checks

Establish how it is mounted:

findmnt -T /informix/chunks -o TARGET,SOURCE,FSTYPE,OPTIONS
mount | grep -E ' ro[, ]'
grep -E ' ro[, ]' /proc/mounts

Then test a write regardless of what that said. For the reasons above, rw in the mount options does not mean the engine can write, and this is the check that settles it:

su - <informix owner> -c 'touch /informix/chunks/.wtest && rm -f /informix/chunks/.wtest' \
    && echo writable || echo "NOT WRITABLE"

Run it as the account that owns the instance. EROFS refuses root as readily as anyone else, so a write that succeeds as root but fails as the owner is not this error at all — that is -13, and the two are easy to conflate when the only evidence is "it cannot write".

A rw mount that genuinely fails this test means the restriction sits below the filesystem: go to blockdev --getro, the device-mapper table, or the storage side.

Then go straight to the kernel log — this is the decisive step. A kernel-imposed remount always says so, and the reason sits immediately above it:

dmesg -T | grep -iE 'remount|read-only|EXT4-fs error|XFS.*error|I/O error|aborting'
journalctl -k --since '1 day ago' | grep -iE 'remount|read-only|error'
grep -iE 'remount|read-only' /var/log/messages | tail -20

A line of the form "Remounting filesystem read-only" preceded by an EXT4-fs error or an I/O error means the kernel protected itself. The lines above the remount are the actual fault; the remount is the consequence.

If there is no such message and fstab explains the mount, it was a choice.

Check the filesystem's recorded state, which persists across the event:

dumpe2fs -h /dev/sdX1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'
xfs_info /informix/chunks 2>/dev/null

Filesystem state: clean with errors, or a non-zero error count with timestamps, is confirmation independent of the logs.

Check whether the device itself is write-protected, which is a different problem from the filesystem being mounted ro:

blockdev --getro /dev/sdX          # 1 = read-only device
cat /sys/block/sdX/ro
multipath -ll | grep -iE 'ro|faulty'

Check the storage layer for the failure that triggered it:

dmesg -T | grep -iE 'medium error|sense|critical|failed|reset'
smartctl -a /dev/sdX | grep -iE 'reallocated|pending|health'

For NFS, the limit may be at the server:

findmnt -T /path -o SOURCE,FSTYPE,OPTIONS
showmount -e <server> 2>/dev/null
# and check the export definition on the server itself

Establish the Informix impact:

onstat -                          # is the server up at all
onstat -d                         # chunk status, if it is
tail -300 "$INFORMIXDIR/tmp/online.log"    # may itself be unwritable
df -h "$INFORMIXDIR" "$INFORMIXDIR/tmp"

Two things to note while reading that. The message log may have stopped at the moment the filesystem went read-only, so the last entry is evidence of when, not of what happened after. And if the instance is down and will not start, the startup attempt's own output matters more than anything in the log — capture it:

oninit -v 2>&1 | tee /tmp/startup.$(date +%s).log

Solutions / Resolution

Do not start by remounting read-write. That is the instinct and it is the one action that can turn a contained incident into data loss.

1. Read the kernel log first and determine which of the two cases you are in. Nothing else should happen before that.
2. If it was deliberate — fstab, a manual mount, an ro export, a snapshot — correct the mount or the export. This case is ordinary configuration work.
3. If the kernel imposed it, treat it as a storage and integrity incident:
   • Stop the instance cleanly if it is still running. Do not leave it writing to whatever else is still writable.
   • Do not remount read-write. Unmount instead.
   • Run a filesystem check offline against the unmounted filesystem, with a backup of the current state if the data matters and no recent archive exists.
   • Investigate the underlying storage — see -5 for the device-versus-path distinction, smartctl, multipath and the sense data.
   • Only after the filesystem and the storage are sound, remount and bring the instance back.
   • Run oncheck against the affected dbspaces before declaring it resolved. A filesystem that went read-only mid-write may have left inconsistent pages.
4. If the device is write-protected, that is a storage-side change and remounting will not help. Escalate with the device name and the timestamps.
5. For containers, fix the volume specification rather than the running container.
6. Verify your backups are readable before any repair step. This is the point at which their condition matters most, and the worst time to find out.
7. Check whether the engine is still running on other filesystems. A partially read-only estate is more dangerous than a cleanly stopped one.

If the engine still will not come online

If the storage has been repaired and the filesystem passes a check, but the instance will not start — or starts and will not bring the dbspace back — stop before running anything that writes to the affected chunks. A filesystem that went read-only mid-write can leave an instance in a state where one wrong recovery step removes the remaining options.

Oninit® are the Down System Specialists. Bringing unresponsive Informix instances back is what we do, and we would far rather hear from you before a recovery attempt than after one.

Examples

The kernel protected itself

$ findmnt -T /informix/chunks -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET            SOURCE      FSTYPE OPTIONS
/informix/chunks  /dev/sdb1   ext4   ro,relatime,errors=remount-ro

$ dmesg -T | grep -iE 'EXT4-fs|remount' | tail -4
[Wed Sep 10 02:14:08 2026] blk_update_request: critical medium error, dev sdb, sector 1954210376
[Wed Sep 10 02:14:08 2026] EXT4-fs error (device sdb1): ext4_find_entry:1455: inode #262145: comm oninit: reading directory lblock 0
[Wed Sep 10 02:14:08 2026] EXT4-fs (sdb1): Remounting filesystem read-only

$ dumpe2fs -h /dev/sdb1 | grep -iE 'state|error count'
Filesystem state:         clean with errors
FS Error count:           3

The mount options still show errors=remount-ro, and the log shows the sequence: medium error, filesystem error, protective remount. Remounting read-write here would put the engine back to writing onto failing media. The device is the problem; the read-only filesystem is the symptom and the protection.

Someone chose it

$ findmnt -T /informix/backups -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET             SOURCE                 FSTYPE OPTIONS
/informix/backups  nas01:/export/backups  nfs4   ro,relatime,vers=4.2

$ dmesg -T | grep -ciE 'remount|EXT4-fs error'
0

$ grep backups /etc/fstab
nas01:/export/backups  /informix/backups  nfs4  ro,_netdev  0 0

No kernel involvement at all — the fstab entry says ro. An export intended for reading archives has been given to a host that also needs to write them. Ordinary configuration work.

The device, not the filesystem

$ blockdev --getro /dev/sdd
1
$ dmesg -T | grep -i sdd | tail -2
[Wed Sep 10 09:02:11 2026] sd 3:0:1:2: [sdd] Write Protect is on
[Wed Sep 10 09:02:11 2026] sd 3:0:1:2: [sdd] Mode Sense: 8f 00 10 08

The LUN is presented read-only. No mount option or filesystem check changes this; the storage team must re-present it read-write. Frequently seen after a failover to a replica that was never promoted.

Platform Note

errno 30 is EROFS on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number is reliable.

The self-protection behaviour exists everywhere but is implemented and reported differently, and that is where the diagnosis happens:

Task	Linux	Solaris	AIX
Mount options	findmnt, /proc/mounts	mount, /etc/mnttab	mount, lsfs
Filesystem errors	dmesg, dumpe2fs -h	fmdump -eV, /var/adm/messages	errpt -a
Check a filesystem	fsck, xfs_repair	fsck, zpool scrub	fsck, logredo
Device write-protect	blockdev --getro	format, luxadm	lsattr -El hdiskN

On ZFS the analogue is a pool suspended or faulted rather than a filesystem remounted, and zpool status reports it directly along with the reason — often more precisely than anything on Linux. On AIX, errpt -a should be the first command, and JFS2 behaves comparably to ext4 in protecting itself.

Related Errors / Related Topics

• -5 — I/O error. Very frequently the cause of a -30: the device fails, the filesystem protects itself, and the error the engine reports is this one rather than the I/O failure that started it. Read both together.
• -28 — No space left on device. The other reason writes stop, and much less serious.
• -13 — Permission denied, worth ruling out when only some writes fail; -30 stops all of them on that filesystem.
• -16 — Device or resource busy, which can appear alongside when trying to unmount for repair.

A -30 on a chunk filesystem is an availability and integrity event, not an error to clear. The order is what matters: kernel log first, remount last — and only after the storage beneath it has been shown to be sound.