Source: OpenMediaVault-Plugin-Developers/openmediavault-flashmemory/issues/33
I have a ROCK64 Armbian OMV tiny NAS system running off a SD card. Hence the need of this plugin. The initial version of OMV installed in it was, I believe, 5.x, which has been dist-upgraded to 7.x along the way.
A couple of days ago, I upgraded its kernel from linux-image-current-rockchip64=24.8.2 (linux-6.6.47) to linux-image-current-rockchip64=25.5.2 (linux-6.12.38) and enabled CGroup v2 by setting kernel param systemd.unified_cgroup_hierarchy=1. Thereafter, I started to run into service start failures related to folder2ram, e.g.
Jul 31 13:15:55 omv systemd[1]: Started minidlna.service - MiniDLNA lightweight DLNA/UPnP-AV server.
Jul 31 13:16:15 omv minidlnad[734]: [2025/07/31 13:16:15] utils.c:295: warn: make_dir: cannot create directory '/var/log/minidlna'
Jul 31 13:16:15 omv minidlnad[734]: minidlna.c:1028: fatal: Failed to open log file '/var/log/minidlna/minidlna.log': No such file or directory
Jul 31 13:16:16 omv systemd[1]: minidlna.service: Main process exited, code=exited, status=255/EXCEPTION
Jul 31 13:16:16 omv systemd[1]: minidlna.service: Failed with result 'exit-code'.
Aug 01 12:42:01 omv folder2ram[297]: start /var/lib/rrdcached
Aug 01 12:42:02 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/df-srv-dev-disk-by-uui>
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/df-root': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/load': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/memory': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/uptime': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/rrdcached': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/df-srv-dev-disk-by-uui>
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/cpu-0': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/cpu-2': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/cpu-3': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/cpu-1': File exists
Aug 01 12:42:05 omv folder2ram[2097]: cp: cannot create directory '/var/lib/rrdcached/db/localhost/nut-apc-bk650': File e>
Aug 01 12:42:05 omv folder2ram[297]: copy files to /var/lib/rrdcached failure, rolling back the mount
I fixed the problem by modifying the folder2ram_startup.service systemd unit.
- After=local-fs-pre.target: local-fs.target is too late for folder2ram
- RequiresMountsFor=/var: all of the folders managed by folder2ram reside in /var
- Wants=tmp.mount: it makes sense for folder2ram to start along with the mounting of the /tmp tmpfs
- Before=rrdcached.service minidlna.service nginx.service nmbd.service: these services need to access folder2ram folders when starting
sudo systemctl edit folder2ram_startup.service --full
sudo reboot
$ cat /etc/systemd/system/folder2ram_startup.service
[Unit]
Description=folder2ram systemd service
After=local-fs-pre.target
After=blk-availability.service
DefaultDependencies=no
RequiresMountsFor=/var
Wants=tmp.mount
Before=rrdcached.service minidlna.service nginx.service nmbd.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/folder2ram -mountall
[Install]
WantedBy=basic.target
The critical-chain of the default folder2ram_startup.service:
$ systemd-analyze critical-chain folder2ram_startup.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
folder2ram_startup.service +40.029s
└─local-fs.target @8.500s
└─run-docker-netns-9d14b9454bcc.mount @55.172s
└─local-fs-pre.target @6.288s
└─systemd-tmpfiles-setup-dev.service @5.810s +476ms
└─systemd-sysusers.service @5.108s +675ms
└─systemd-remount-fs.service @4.789s +238ms
└─systemd-journald.socket @4.353s
└─system.slice @4.175s
└─-.slice @4.175s
After modification:
$ systemd-analyze critical-chain folder2ram_startup.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
folder2ram_startup.service +37.382s
└─local-fs-pre.target @6.142s
└─systemd-tmpfiles-setup-dev.service @5.633s +507ms
└─systemd-sysusers.service @5.013s +582ms
└─systemd-remount-fs.service @4.781s +191ms
└─systemd-journald.socket @4.377s
└─system.slice @4.206s
└─-.slice @4.205s
Source: OpenMediaVault-Plugin-Developers/openmediavault-flashmemory/issues/33
I have a ROCK64 Armbian OMV tiny NAS system running off a SD card. Hence the need of this plugin. The initial version of OMV installed in it was, I believe, 5.x, which has been dist-upgraded to 7.x along the way.
A couple of days ago, I upgraded its kernel from linux-image-current-rockchip64=24.8.2 (linux-6.6.47) to linux-image-current-rockchip64=25.5.2 (linux-6.12.38) and enabled CGroup v2 by setting kernel param systemd.unified_cgroup_hierarchy=1. Thereafter, I started to run into service start failures related to folder2ram, e.g.
I fixed the problem by modifying the folder2ram_startup.service systemd unit.
The critical-chain of the default folder2ram_startup.service:
After modification: