Where everything is stored

The QNX Neutrino operating system doesn't prescribe a specific layout of the filesystem hierarchy, and a system designer is generally free to structure files in a way that fits the goals of the system.

For example, a multiuser system that's built around generic open-source components may benefit from following the traditional UNIX filesystem layout (see http://www.pathname.com). On the other hand, a secure embedded system may be better off with a layout that avoids union paths (i.e., any path serviced by more than one resource manager) and where some files are restricted to read-only, verified, and potentially encrypted filesystems.

The layout of files in a QNX Neutrino system is primarily determined by the following:

Filesystem resource managers, including the one that provides the main image filesystem (IFS), can be mounted at any point in the path space. The IFS is mounted at / by default and prepends the prefix proc/boot to all objects in the IFS. This has the effect that the procfs (/proc resource manager) is always questioned first for any file that starts with /proc/boot from the IFS, which affects performance slightly. You can avoid this issue by using the [prefix=""] and [mount="/ifs"] options in your mkifs buildfile to mount the IFS at /ifs instead.

When you're populating a filesystem that can be mounted anywhere, avoid absolute paths and any assumptions as to where the filesystem is mounted. For example, the path lib/libfoo.so in a Power-Safe filesystem can become /lib/libfoo.so if the filesystem is mounted at the root of the path space, or /fs/qnx6/lib/libfoo.so if it's mounted at /fs/qnx6. The system's path manager ensures that requests for this path are routed to the correct resource manager.

Many device-specific resource managers (unlike filesystem resource managers) hard-code their mountpoints, typically under /dev. This is rarely a requirement, though, and if you find that a device resource manager conflicts with the layout of your system, you may wish to contact the provider of the resource manager so that they can change that (or, better yet, let you specify the mountpoint via a command-line option or an environment variable).

Nevertheless, there are a few paths that must exist in a QNX Neutrino system:

/usr/lib/ldqnx.so.2 or /usr/lib/ldqnx-64.so.2
The runtime linker (also known as the dynamic linker). This path is hard-coded in any QNX Neutrino executable.
/.boot (x86_64 only)
A directory that contains any IFS binaries and is required by BIOS-based systems.

The rest of this section describes the QNX Neutrino version of the traditional UNIX layout.


The /bin directory contains binaries of essential utilities, such as chmod, ls, and ksh.

To display basic utility syntax, type use utilityname from the command line. For more information, see use in the Utilities Reference.


The /dev directory belongs to the process manager and contains device files, possibly including:

CD-ROM block devices; see devb-* in the Utilities Reference for driver information.
Text mode console TTY device; see devc-con in the Utilities Reference.
The device that's used for diagnostic log messages; on a full x86 system, this is a write-only device managed by the system logger, slogger2. Buildfiles for embedded systems may configure a link from this path to another device, such as a serial port. See slogger2 in the Utilities Reference.
Hard disk block devices; data representing an entire drive, spanning all partitions; see devb-* in the Utilities Reference.
Hard disk partition block devices; the data in these devices is a subset of that represented by the corresponding hdn file; see devb-* in the Utilities Reference.
A device that represents all physical memory.
/dev/mq and /dev/mqueue
A pathname space where entries for message queues appear; for more information, see mq and mqueue in the Utilities Reference.
A “bit bucket” that you can direct data to. The data is discarded.
Adopted by the PCI server on the machine, this device lets programs communicate with the PCI server. See pci-* in the Utilities Reference.
Adopted by the pipe manager. The presence of this file tells other programs (such as a startup script built into an OS image) that the Pipe manager is successfully running.
The control side of a pseudo-terminal device pair. Pseudo-ttys are named with a letter (p–z or P–T) followed by a hexadecimal digit, making it possible to have up to 256 devices. See devc-pty in the Utilities Reference.
Read from this device to obtain random data; see random in the Utilities Reference.
A pathname space where entries for named semaphores appear.
Serial ports. See stty for configuration, and devc-ser* for driver details in the Utilities Reference.
Contains files representing shared memory regions on the system (also sometimes used for generic memory-mapped files). For more information, see the description of the RAM “filesystem” in Working with Filesystems.
This directory is owned and managed through the TCP/IP stack, which is included in io-pkt*. This directory contains pathnames through which applications interact with the stack. For more information, see the TCP/IP Networking chapter in this guide.
This file is managed by procnto. Text written to this device is output through debug output routines encoded in the startup code for your system, so the actual result varies from board to board. On a standard PC, the default is to write to the PC console. For more information, see startup-* in the Utilities Reference.
A virtual device owned by the process manager (procnto) that resolves to the controlling terminal device associated with the session of any process that opens the file. This is useful for programs that may have closed their standard input, standard output, or standard error, and later wish to write to the terminal device.
The slave side of the corresponding /dev/pty[p-zP-T][0-9a-f] file. The program being controlled typically uses one of these files for its standard input, standard output, and standard error.
Supplies an endless stream of bytes having a value of zero.


The /etc directory contains host-specific system files and programs used for administration and configuration, including:

A directory that contains system-configuration files, such as the ttys file that tinit uses to configure terminal devices.
A directory that contains default configuration files, primarily for TCP/IP facilities.
Dynamic Host Configuration Protocol configuration; see /etc/dhcpd.conf in the Utilities Reference.
Configuration options for ftpd that apply once you've authenticated your connection. See ../../com.qnx.doc.neutrino.utilities/topic/f/ftpd.conf.html in the Utilities Reference.
Defines users who may access the machine via the File Transfer Protocol. See /etc/ftpusers in the Utilities Reference.
User account group definitions; see Managing User Accounts.
Network hostname lookup database; see also /etc/nsswitch.conf and /etc/resolv.conf, below. See /etc/hosts in the Utilities Reference.
Internet super-server configuration file that defines Internet services that inetd starts and stops dynamically as needed.
Note: The descriptions in the default version of this file are commented out; uncomment the ones that you want to use. See /etc/inetd.conf in the Utilities Reference.
Contains an ASCII message of the day that may be displayed when users log in, as long as /etc/profile is configured to display it.

The default /etc/profile displays this file only if the /etc/motd file is more recent than the time you last logged in to the system, as determined by the time your $HOME/.lastlogin file was last modified. For more information, see the description of /etc/profile in Configuring Your Environment.

Network name database file. For more information, see /etc/networks in the Utilities Reference.
Name-service switch configuration file. For more information, see /etc/nsswitch.conf in the Utilities Reference.
Backup of /etc/passwd file before its last change via the passwd utility. See the Managing User Accounts chapter.
Backup of /etc/shadow file before its last change via the passwd utility. Managing User Accounts.
This file defines login accounts. See the chapter Logging In, Logging Out, and Shutting Down, as well as Managing User Accounts for more details; also see passwd, login in the Utilities Reference.
The startup profile script executed by the shell when you log in; it's executed before $HOME/.profile. See Configuring Your Environment.
A directory where the default /etc/profile script looks for scripts to run when any user logs in. The /etc/profile script runs each script in this directory that matches *.$(SHELL##*/}. For example, if the value of the SHELL environment variable is /bin/sh, the script runs the scripts that match *.sh.
Resolver configuration file; see also /etc/hosts, above. See /etc/resolv.conf in the Utilities Reference.
A directory that holds the default version of .profile. When you add a new user to the system, this file is copied to the user's home directory. For more information, see the description of /etc/default/passwd in the documentation for passwd, and the description of .profile in Configuring Your Environment.


The home directories of regular users are found here. The name of your home directory is often the same as your user name. You can create whatever directory structure you need inside your home directory.


This directory contains essential shared libraries that programs need in order to run (filename.so), as well as static libraries used during development. See also /usr/lib and /usr/local/lib.

The /lib directory includes:

Contains additional shared libraries that implement OS drivers and services, such as drivers, filesystem managers, and so on. For some examples of how shared libraries are used for certain types of drivers and services, see Filesystems, Native Networking (Qnet), and TCP/IP Networking in the System Architecture guide. For details about specific shared objects in the /lib/dll directory, see their respective entries in the Utilities Reference.


Owned by the process manager (procnto), this virtual directory can give you information about processes and pathname-space configuration.

The /proc directory contains a subdirectory for each process; the process ID is used as the name of the directory. Each of these directories contains entries that you can (with the appropriate permission) use to access the process's address space, control its threads, and so on. Various utilities use this entry to get information about a process. For more information, see Controlling processes via the /proc filesystem in the Processes chapter of the QNX Neutrino Programmer's Guide, and the /proc Filesystem appendix of The QNX Neutrino Cookbook.

The /proc directory also includes:

The image filesystem that comprises the boot image. For more information, see OS Images in Building Embedded Systems.
A special entry that receives notification when a process terminates abnormally. The dumper utility creates this entry.
Pathname-space mountpoints.
Note: If you list the contents of the /proc directory, /proc/mount doesn't show up, but you can list the contents of /proc/mount.

For more information, see The /proc/mount directory in the /proc Filesystem appendix of The QNX Neutrino Cookbook.

If you're using Transparent Distributed Processing (TDP), the lsm-qnet.so module places a qnetstats entry in /proc. If you open this name and read from it, the Qnet resource manager code responds with the current statistics for Qnet.
The address space for yourself (i.e., for the process that's making the query).


The /root directory is the home directory for the root user.


This directory contains essential system binaries, including:


This directory contains temporary files. Programs are supposed to remove their temporary files after using them, but sometimes they don't, either due to poor coding or abnormal termination. You can periodically clean out extraneous temporary files when your system is idle.


The /usr directory is a secondary file hierarchy that contains shareable, read-only data. It might include the following:

A directory that contains most user commands. Examples include diff, errno, and wc.
Object files, libraries, and internal binaries that you shouldn't execute directly or in scripts. You'll link against these libraries if you write any programs.
A directory that could contain system daemons and system utilities; in general, these are run only by other programs.
A directory where the system administrator can install software locally. It's initially empty.
Nonessential system binaries, such as cron, dumper, and nicinfo.
Data that's independent of the architecture, such as icons, backdrops, and various gawk programs.


The /var directory contains variable data files, including cache files, lock files, log files, and so on.

The directory where the Persistent Publish/Subscribe manager, pps, stores (“persists”) its state on shutdown.