12.3 File Systems

The list of file systems to be mounted is specified in the file-systems field of the operating system declaration (see Using the Configuration System). Each file system is declared using the file-system form, like this:

(file-system
  (mount-point "/home")
  (device "/dev/sda3")
  (type "ext4"))

As usual, some of the fields are mandatory—those shown in the example above—while others can be omitted. These are described below.

Data Type: file-system

Objects of this type represent file systems to be mounted. They contain the following members:

type

This is a string specifying the type of the file system—e.g., "ext4".

mount-point

This designates the place where the file system is to be mounted.

device

This names the “source” of the file system. It can be one of three things: a file system label, a file system UUID, or the name of a /dev node. Labels and UUIDs offer a way to refer to file systems without having to hard-code their actual device name²⁸.

File system labels are created using the file-system-label procedure, UUIDs are created using uuid, and /dev node are plain strings. Here’s an example of a file system referred to by its label, as shown by the e2label command:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (file-system-label "my-home")))

UUIDs are converted from their string representation (as shown by the tune2fs -l command) using the uuid form²⁹, like this:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))

When the source of a file system is a mapped device (see Mapped Devices), its device field must refer to the mapped device name—e.g., "/dev/mapper/root-partition". This is required so that the system knows that mounting the file system depends on having the corresponding device mapping established.

flags (default: '())

This is a list of symbols denoting mount flags. Recognized flags include read-only, bind-mount, no-dev (disallow access to special files), no-suid (ignore setuid and setgid bits), no-atime (do not update file access times), no-diratime (likewise for directories only), strict-atime (update file access time), lazy-time (only update time on the in-memory version of the file inode), no-exec (disallow program execution), and shared (make the mount shared). See Mount-Unmount-Remount in The GNU C Library Reference Manual, for more information on these flags.

options (default: #f)

This is either #f, or a string denoting mount options passed to the file system driver. See Mount-Unmount-Remount in The GNU C Library Reference Manual, for details.

Run man 8 mount for options for various file systems, but beware that what it lists as file-system-independent “mount options” are in fact flags, and belong in the flags field described above.

The file-system-options->alist and alist->file-system-options procedures from (gnu system file-systems) can be used to convert file system options given as an association list to the string representation, and vice-versa.

mount? (default: #t)

This value indicates whether to automatically mount the file system when the system is brought up. When set to #f, the file system gets an entry in /etc/fstab (read by the mount command) but is not automatically mounted.

needed-for-boot? (default: #f)

This Boolean value indicates whether the file system is needed when booting. If that is true, then the file system is mounted when the initial RAM disk (initrd) is loaded. This is always the case, for instance, for the root file system.

check? (default: #t)

This Boolean indicates whether the file system should be checked for errors before being mounted. How and when this happens can be further adjusted with the following options.

skip-check-if-clean? (default: #t)

When true, this Boolean indicates that a file system check triggered by check? may exit early if the file system is marked as “clean”, meaning that it was previously correctly unmounted and should not contain errors.

Setting this to false will always force a full consistency check when check? is true. This may take a very long time and is not recommended on healthy systems—in fact, it may reduce reliability!

Conversely, some primitive file systems like fat do not keep track of clean shutdowns and will perform a full scan regardless of the value of this option.

repair (default: 'preen)

When check? finds errors, it can (try to) repair them and continue booting. This option controls when and how to do so.

If false, try not to modify the file system at all. Checking certain file systems like jfs may still write to the device to replay the journal. No repairs will be attempted.

If #t, try to repair any errors found and assume “yes” to all questions. This will fix the most errors, but may be risky.

If 'preen, repair only errors that are safe to fix without human interaction. What that means is left up to the developers of each file system and may be equivalent to “none” or “all”.

create-mount-point? (default: #f)

When true, the mount point is created if it does not exist yet.

mount-may-fail? (default: #f)

When true, this indicates that mounting this file system can fail but that should not be considered an error. This is useful in unusual cases; an example of this is efivarfs, a file system that can only be mounted on EFI/UEFI systems.

dependencies (default: '())

This is a list of <file-system> or <mapped-device> objects representing file systems that must be mounted or mapped devices that must be opened before (and unmounted or closed after) this one.

As an example, consider a hierarchy of mounts: /sys/fs/cgroup is a dependency of /sys/fs/cgroup/cpu and /sys/fs/cgroup/memory.

Another example is a file system that depends on a mapped device, for example for an encrypted partition (see Mapped Devices).

Scheme Procedure: file-system-label str

This procedure returns an opaque file system label from str, a string:

(file-system-label "home")
⇒ #<file-system-label "home">

File system labels are used to refer to file systems by label rather than by device name. See above for examples.

The (gnu system file-systems) exports the following useful variables.

Scheme Variable: %base-file-systems

These are essential file systems that are required on normal systems, such as %pseudo-terminal-file-system and %immutable-store (see below). Operating system declarations should always contain at least these.

Scheme Variable: %pseudo-terminal-file-system

This is the file system to be mounted as /dev/pts. It supports pseudo-terminals created via openpty and similar functions (see Pseudo-Terminals in The GNU C Library Reference Manual). Pseudo-terminals are used by terminal emulators such as xterm.

Scheme Variable: %shared-memory-file-system

This file system is mounted as /dev/shm and is used to support memory sharing across processes (see shm_open in The GNU C Library Reference Manual).

Scheme Variable: %immutable-store

This file system performs a read-only “bind mount” of /gnu/store, making it read-only for all the users including root. This prevents against accidental modification by software running as root or by system administrators.

The daemon itself is still able to write to the store: it remounts it read-write in its own “name space.”

Scheme Variable: %binary-format-file-system

The binfmt_misc file system, which allows handling of arbitrary executable file types to be delegated to user space. This requires the binfmt.ko kernel module to be loaded.

Scheme Variable: %fuse-control-file-system

The fusectl file system, which allows unprivileged users to mount and unmount user-space FUSE file systems. This requires the fuse.ko kernel module to be loaded.

The (gnu system uuid) module provides tools to deal with file system “unique identifiers” (UUIDs).

Scheme Procedure: uuid str [type]

Return an opaque UUID (unique identifier) object of the given type (a symbol) by parsing str (a string):

(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")
⇒ #<<uuid> type: dce bv: …>

(uuid "1234-ABCD" 'fat)
⇒ #<<uuid> type: fat bv: …>

type may be one of dce, iso9660, fat, ntfs, or one of the commonly found synonyms for these.

UUIDs are another way to unambiguously refer to file systems in operating system configuration. See the examples above.

• Btrfs file system