Overlay file system


A PLCnext Control usually has two data storage media:

  • An internal parameterization memory
  • An SD card
    The SD card is mandatory for some controllers, and for others it is optional. Check the user manual of your PLCnext Control for more information.

Each data storage medium is divided into one or more partitions.

The PLCnext firmware uses an Overlay File System (OverlayFS) to combine contents of a read-only partition with a read-write partition. The read-only partition is always stored in the internal parameterization memory of the controller. This partition contains the initial firmware and is updated upon each firmware update. In fact, this is a set of 3 partitions:

  • Active boot partition
    The controller boots from the active boot partition.
  • Inactive boot partition
    In case of a firmware update the new firmware is copied into the inactive boot partition. When the copying process is completed, the inactive and active partitions change their roles. The firmware update is finished by booting from the updated partition.
  • Recovery partition
    The recovery partition contains (a copy of) the firmware which has been installed to the PLCnext controller during its manufacturing process. This partition plays a role when performing a reset to default setting type 2 (see below).
Note: If the boot process failed several consecutive times, the inactive and the active boot partition will change their roles, too. This behavior has been implemented to keep the PLCnext Control device accessible even if the firmware update fails. The behavior can also occur when the boot process is interrupted e.g. by power loss. In this case you will observe that the PLCnext Control boots with its previously installed firmware version.
To prevent such unintended firmware downgrades, Phoenix Contact recommends that after a finally successful firmware update, the same firmware should be installed once again. This way both the active and the inactive boot partition contain the same firmware version.

File handling

In an early phase of the boot process the read-only active boot partition is integrated with the read-write partition. The read-write partition is stored either at the external SD card or in a dedicated partition of the internal parameterization memory if no SD card is present. This integration affects the handling of files during operation of the controller as follows:

  • New files (not present in the read-only partition) are stored in the read-write partition.
  • Changed files are stored in the read-write partition. The initial file remains unchanged at the read-only partition. Access to the initial file is not intended.
  • Removed files are indicated as deleted in the read-write partition although the initial file remains unchanged in the read-only partition. It can no longer be accessed.

This means besides its regular path, a file is also listed at one or two further paths in the file system (depending on your PLCnext Control model). These further paths indicate the partition used to store the file. Normally you neither recognize nor have to worry in which partition a certain file is stored because this is managed in the background by the OverlayFS. In rare cases it may be interesting which file is stored in the read-write partition. For these cases both partitions are mapped into the controller’s directory structure:

  • /media/rfs/ro is the root of the read-only partition. Files in this partition cannot be changed but may be read for information or comparison reasons. Files in this partition are replaced (respectively removed) during a firmware update.
  • /media/rfs/rw/upperdir is the root of the read-write partition, where new, changed and removed files are stored. Files in this partition are usually not changed during a firmware update. The OverlayFS integrates all files stored here into the root folder of the file system.
    Note: After manipulating files in the upperdir folder, it is recommended to reboot the controller. Otherwise it is undetermined when these changes become active.

Example on read-only and read-write partitionExample on read-only and read-write partition

The NTP configuration is listed at /etc/ntp.conf. This file comes with the firmware and is therefore located at /media/rfs/ro/etc/ntp.conf. Once you have edited this file, the changed file will be located at /media/rfs/rw/upperdir/etc/ntp.conf . This file will be used when accessing /etc/ntp.conf. Even if you edit this file back to its initial content, this situation continues.

Note when changing firmware files:

Problems may occur when updating or downgrading the firmware. Let’s consider you have changed a file which comes with the firmware, and later you update the firmware with an updated content of this file. Then your changed file will remain in operation because the content updated by the firmware resides in the read-only partition, and the OverlayFS will prefer the file of the read-write partition. In case of the previous example this means that /media/rfs/rw/upperdir/etc/ntp.conf is still accessed as /etc/ntp.conf, too. 

For this reason it is generally recommended to never edit or remove files that are installed with the firmware. This also applies to changes by means of the operating system, which also includes that some Linux® commands like adduser implicitely write to files which are stored in the overlayFS. That's why the default admin user has no permission to execute such commands.

If you run into trouble caused by changes in the upperdir folder as described above:

  • Try to remove the offending file(s) from the upperdir folder, and then restart the controller.
  • If this does not work (or if you cannot identify the offending files) perform a reset to default setting type 1.

Files on an SD card

In case the read-write partition is stored at the SD card, the configuration and project files can easily be transferred to another controller by removing the SD card from one controller and inserting it into another controller. Please note that licenses are bound to the device and therefore are stored at the device (not at the SD card).

Security note: The SD card can be read with a conventional SD card reader at any time, and sensitive data on the SD card can be read by unauthorized persons.
  • Physically protect the SD card against unauthorized access.
  • Ensure that unauthorized persons do not have access to the SD card.

Reset to default setting type 1 and type 2

A detailed description of how to perform the reset to default setting type 1 or type 2 on your controller can be found in the corresponding user manual. The two reset types perform the following actions on the partitions of the controller:

Reset to default setting type 1

This process clears the read-write partition (i.e. all files in /rfs/rw/upperdir/). During the following boot process the initial files of the read-only boot partition become active again.

Reset to default setting  type 2

This process clears the read-write partition, just like reset to default setting type 1. In addition, the firmware contained in the recovery partition is copied to the inactive boot partition. Thereafter the inactive and active partitions change their roles, and the reset to default setting type 2 is finished by booting from the updated partition.

Note: It is also possible to store user files outside the upperdir directory (e.g. OCI images are not installed in the upperdir directory).
Files that are stored outside the upperdir directory are not deleted during a reset to default setting type 1 or type 2. So in this case not necessarily all user files are deleted and a reset to default setting type 2 does not necessarily restore the controller to factory default state.


•  Web browser recommendation: Chrome/Edge 88 or newer, Firefox ESR 90 or neweror Safari • 
• Published/reviewed: 2022-09-14 • Revision 046 •