Informix Error -66

-66 Directory not empty.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. Look for other operating-system error messages that might give more information, particularly what directory was being removed. If the error recurs, note all circumstances and contact IBM Informix Technical Support.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning

	Value	Symbol
Catalogue text — Directory not empty	66	`ENOTEMPTY` on BSD
The same condition on Linux	39	`ENOTEMPTY`
Errno 66 on Linux	66	`EREMOTE` — Object is remote; see -71

Another code whose condition Linux reports at a much lower number.

python3 -c 'import os; print(39, os.strerror(39)); print(66, os.strerror(66))'

On Linux, ENOTEMPTY is errno 39, so the engine reports it as -39. The full treatment is there:

Error -39 — why a directory that looks empty is not, NFS silly-rename entries, the four ways rmdir fails, and the cleanup-script patterns that cause it.

The Condition, in Short

rmdir() was called on a directory that still has entries, or rename() tried to replace a directory that is not empty.

Most of the time that needs no explanation. The case that does is the directory that looks empty and is not, for three reasons:

Dotfiles, which ls does not show and ls -A does.
NFS silly-rename entries. A file deleted on an NFS mount while something still holds it open is renamed to .nfs followed by a hex string, and persists until the last handle closes.
A concurrent writer, so the directory is never empty at the moment anyone looks.

It is also worth separating from the three errors that look identical inside a script — EBUSY for a mount point or somebody's working directory, EACCES for an unwritable parent, and ENOENT for a path already gone. That table is on -39.

About the Official Text

The catalogue advises looking for other messages that identify which directory was being removed, and that is the right instinct — the engine reports the errno without necessarily naming the path, and the path is the whole diagnosis.

Where a cleanup runs unattended, having it print the contents of the directory on failure turns this into a five-second answer rather than an investigation. That and the rest of the practical material are on -39.

Diagnostic Checks

Confirm the symbol, which decides which page applies:

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

Result	Meaning	Read
`Directory not empty`	`ENOTEMPTY` — BSD or System V	this condition, detail on -39
`Object is remote`	`EREMOTE` — Linux errno 66	-71, a different condition

If it is ENOTEMPTY, look properly before anything else:

ls -A /path/to/dir                       # includes dotfiles
ls -A /path/to/dir | grep '^\.nfs'       # NFS silly-rename entries
find /path/to/dir -mindepth 1 | head -20

On a Linux host, expect this condition at -39 rather than here.

Solutions / Resolution

Confirm the symbol first. On Linux, errno 66 is EREMOTE and this code is not what you have.
Run ls -A. It resolves the majority of these in one command.
If they are .nfs files, do not force the removal. Something still has the underlying file open; find it, let it finish, and the entries go by themselves. Deleting them out from under a running reader is how a backup ends up truncated.
If the instance is writing there, the cleanup is the problem, not the filesystem — a retention job that cannot remove a directory because the engine is using it has found a scheduling fault.
For everything else, go to -39, which carries the script patterns and the full diagnostic sequence.

Platform Note

Platform	`ENOTEMPTY` is	Errno 66 there means
Linux	errno 39 — reported as -39	`EREMOTE`, Object is remote — see -71
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 66	this condition

As with -62 and -63, the catalogue carries one condition at two codes: this entry from the BSD numbering, and -39 from the value Linux uses. A Linux instance reports -39.

The NFS silly-rename behaviour is a property of the NFS client rather than of the platform, so it appears wherever NFS is mounted — and the .nfs prefix is what to look for on all of them.

Related Errors / Related Topics

-39 — where this condition is reported on Linux, and where the full treatment lives.
-16 — Device or resource busy. A directory that is a mount point or a process's working directory refuses removal while being genuinely empty, which is a different fault entirely.
-71 — what errno 66 means on Linux.

Where -66 appears, confirm the symbol and then read -39. On a Linux host this condition does not carry this number.