| Previous | Next |
| EXDEV | ENOTDIR |
ENODEV
Not limited to an unplugged device
ENODEV names a missing or unusable device-like facility, but the exact object depends on the call that returned it. For example, Linux mmap() can return ENODEV when the filesystem behind a file does not support memory mapping. Linux pidfd_open() can use the same code when the kernel lacks the anonymous-inode filesystem needed to create a PID file descriptor.
This makes ENODEV a capability diagnosis rather than proof that a pathname is misspelled. For an open() call on a device special file, Linux documents a no-device case as ENXIO and notes that an ENODEV result there is a kernel bug. The distinction must therefore be interpreted from the exact API, object type, and platform, not from the symbolic name alone.
How to investigate
- Record the function, pathname or descriptor, flags, object type, and—when relevant—the device major/minor numbers or filesystem type.
- For a device node, verify that it maps to the intended driver-backed device; recreating a node with the same filename does not make an absent device available.
- For a mapping request, check whether the target filesystem implements memory mapping and choose a supported I/O path only when the application design permits it.
- For optional kernel facilities, expose a capability check or a clearly documented unsupported-feature path instead of retrying the same request blindly.
References
Looking for a different code? Search another status or error code.