I have OpenWRT installed on some of my routers and to add additional storage for settings as well as programs that might be installed on the router and maybe logs, OpenWRT recommends you plug storage into it and use an overlayfs. I also have a SBC where I just mount an external drive overtop of my home directory on boot to store the home directory externally off of the SD Card that the bootloader and OS are installed on; since the storage on the external drive is more reliable than the SD Card, despite running slower. What is the difference between these two strategies? They are both basically Single Board computers with Linux, and when the external drive fails to mount, in both cases we're left with a directory full of the content of the original directory, where the drive would have been mounted before. The only think I can think of that is different, is that the settings directory for OpenWRT (/etc) is being mounted on the external drive, where this is not the case on the SBC.

Is it possible to mount an Overlayfs filesystem as an unprivileged user in a user namespace in Linux kernels >4.3.3; it seems that the fix to this vulnerability has blocked this functionality entirely. When I create a new user namespace with clone() , passing the CLONE_NEWNS flag and attempt to invoke mount with an overlayfs filesystem, I'm given permission denied. I can mount any other filesystem though. Is there a way to work around this/am I missing something?

I'm writing a program to allow unprivileged users to mount overlay filesystems using a setuid binary. I've implemented a few safeguards to improve the program's security, but I'd like a more definitive checklist of potential security risks such a program might expose. Here are the safeguards I've implemented so far: - The program dissociates its mount namespace before performing any mounts, ensuring that other processes remain unaffected by the new mount. The program then runs a user-provided command inside that namespace. - It verifies that every lowerdir is readable by the user. For sub-items within each lowerdir, I assume that POSIX ACLs will prevent unauthorized access. - It ensures that the upperdir is both readable and writable by the user. Again, I rely on ACLs to enforce access restrictions on sub-items. - It verifies that the workdir is writable. Since the workdir must be empty for OverlayFS to function, I consider the risk there to be minimal. - It ensures that the mountpoint is writable by the user. - The program resets the effective UID and GID to the real user’s IDs immediately after completing the mount operations. These measures cover all the attacks I could foresee, but I suspect there may be additional risks I haven't accounted for. I would appreciate it if someone could point out any security issues before this goes into production.

How do I install and enable the overlay2 storage driver on CentOS 7? I have done many google searches on this and I see that version 7.4 is required. So I typed the following commands to confirm that the intended server is running version 7.4 of CentOS: [sudoUser@localhost ~]$ cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) [sudoUser@localhost ~]$ rpm --query centos-release centos-release-7-4.1708.el7.centos.x86_64 [sudoUser@localhost ~]$ But there does not seem to be any yum install overlay2 or yum install overlayfs. >**So what specific steps are required in order to install and enable overlay2 on CentOS 7.4?**

My embedded Linux system, which uses a SquashFS as its root filesystem, has unexpectedly stopped booting. The system is designed with an OverlayFS mounted on a temporary RAM disk to provide read-write capabilities while maintaining a reliable, read-only SquashFS base. The core issue appears to be a corrupted SquashFS root filesystem. My understanding was that even if the OverlayFS experienced an issue (e.g., memory corruption in the RAM disk), it should be impossible for the operating system to modify the underlying SquashFS, as SquashFS is inherently read-only. Given this setup, what are the possible mechanisms that could lead to a corrupted SquashFS root filesystem? System Details (to the best of my knowledge, more can be provided if necessary): * Root Filesystem: SquashFS * Read-Write Layer: OverlayFS on a RAM disk (tmpfs) * Bootloader: GRUB * Storage Medium for SquashFS: NAND * Kernel Version: Linux 4.19.155 * Hardware Platform: Intel x64 What I've already considered (and why I think it's unlikely, but open to correction): * OverlayFS issues: I believe problems with the OverlayFS (e.g., corruption of the upperdir or workdir) should only affect the writable layer and not propagate to the read-only lower SquashFS. * Normal operation: The system's design is specifically to prevent writes to the SquashFS during normal runtime. My main question revolves around how a fundamentally read-only filesystem, protected by an OverlayFS, could become corrupted. Any insights into software failures, hardware failures, or misconfigurations that could lead to this situation would be greatly appreciated.

The commands below should be creating a root overlay, such that any modifications to root will appear in /tmp/upper However as you can see it does not appear to be working. Can anyone suggest what I am doing wrong? I am following the syntax here: https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt thanks ubuntu@ip-10-0-0-48:~$ sudo su root@ip-10-0-0-48:/home/ubuntu# cd /tmp root@ip-10-0-0-48:/tmp# mkdir upper root@ip-10-0-0-48:/tmp# mkdir workdir root@ip-10-0-0-48:/tmp# mount -t overlay overlay -olowerdir=/,upperdir=/tmp/upper,workdir=/tmp/workdir / root@ip-10-0-0-48:/tmp# touch /floob root@ip-10-0-0-48:/tmp# ls / bin boot dev etc floob home initrd.img lib lib64 lost+found media mnt opt proc root run sbin snap srv sys tmp usr var vmlinuz x root@ip-10-0-0-48:/tmp# ls /tmp/upper/ root@ip-10-0-0-48:/tmp#

Lets say I have two devices: - /dev/sda1 mounted to / (system partition) - /dev/sdb1 mounted to /media/data (data partition, usb device may be unplugged) I want to merge/overlay/raid two directories like so: - /media/data is the primary directory - /usr/data is the backup/failover directory that exists on the system partition The resulting directory (e.g /mnt/merged) will consist of the above two directories so that: - when writing a file to /mnt/merged the file will be written to /media/data - if the /dev/sdb1 is not available while writing (the usb storage is removed) then write to the backup /usr/data and when the primary partition is plugged again move the data to the primary partition - (optional) setup the second partition as a cache partition in case it is faster than the primary partition, so that reads and writes happen to the backup (faster) directory before moving to the primary directory

Is it possible to union-mount an existing disk image containing a root filesystem to the upperdir of an overlayfs mount for read-write access? I'm trying to union-mount some old disk images to a /tmp/ directory on an Ubuntu 16.04 machine using pre-existing scripts (originally written on Ubuntu 12.04 and ported to 14.04). The old automation scripts used overlayfs to create and union-mount writable ext2/3 disk images on top of squashfs images — something like this: cd /tmp mkdir lower upper union losetup /dev/loop1 /tmp/image.sfs losetup /dev/loop2 /tmp/image.ext2 mount -t squashfs -o ro /dev/loop1 /tmp/lower mount -t ext2 -o rw /dev/loop2 /tmp/upper mount -t overlayfs -o rw,lowerdir=/tmp/lower,upperdir=/tmp/upper overlayfs /tmp/union They were last used on an 3.x kernel (likely pre-3.18), and that method doesn't seem to work anymore. Overlay now requires a workdir option—e.g.: mount -t overlay -o rw,lowerdir=/tmp/lower,upperdir=/tmp/upper,workdir=/tmp/work overlay /tmp/union **Q:** Is it possible to tweak the automation scripts to mount and use the existing images in a writable state on a 4.x kernel? Can I avoid reformulating them to contain something like root and work directories? In some cases that may break their use elsewhere. Per the documentation, the workdir has to be an empty directory on the same filesystem as the upperdir to allow for atomic writes. That sounds to me like it is impossible to union-mount root filesystem images as read-write. The workdir would have to exist within the images (separate from their data directory) which isn't possible in a root filesystem image. I've considered loading up stock Ubuntu 14.04 in a VM for a couple one-offs, but it's not a long term solution. --- **Best Attempt So Far:** The only solution I've come up with that avoids double-writing the same data to disk is to mount both images as lowerdir values, with upperdir and workdir directories sitting on a tmpfs mount. Then I can use rsync to copy the changes from the tmpfs location to the mounted ext2/3 image after the automated writes are complete and the overlay union has been unmounted—i.e.: mount -t overlay -o rw,lowerdir=/tmp/upper:/tmp/lower,upperdir=/tmp/tmpfs/root,workdir=/tmp/tmpfs/work overlay /tmp/union ...perform automated reads/writes... umount /tmp/union ...rsync contents from /tmp/tmpfs/root to /tmp/upper... It's strictly limited to available RAM, though, and it's an ugly hack to add to all of the automation scripts.

I have two hard drives, each with a single partition (/dev/sda1 and /dev/sdb1). The Linux root is on /dev/sda1. I run the following script.

mount /dev/sdb1 /mnt
mkdir /data /mnt/upper /mnt/work

mount -t overlay overlay -o lowerdir=/data,upperdir=/mnt/upper,workdir=/mnt/work /data

umount /mnt

I noticed two interesting behaviors here. 1. The overlay **overwrites its own** lowerdir (since /data is both the lowerdir and the mount target). 2. The overlay **continues working correctly** even after unmounting /dev/sdb1 (which holds upperdir and workdir). **Is this behavior reliable?** I couldn't find any documentation about this behavior in either the [mount(8)](https://man.archlinux.org/man/mount.8.en) man page or the official [OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html) documentation. While eliminating extra mount points would be convenient, can this approach be considered truly reliable? **Here’s another example that also raises doubts.**

mount /dev/sdb1 /mnt
mkdir /mnt/dir
mount --bind /mnt/dir /dir
umount /mnt

Is the same mechanism at work here? Is this just as (un)reliable as the OverlayFS example?

I'm working on an embedded device with an arm cortex A9. The kernel version is 4.16.0 and is generated by buildroot 2018.05. The storage memory is an mmc with several partition. U-boot reads the uImage in one partition and starts the kernel. The filesystem is included in the kernel image and is loaded at startup in an initramfs (config : BR2_TARGET_ROOTFS_INITRAMFS). I want to use an overlayfs to use a folder (in the mmc) as a 'user' filesystem, mounted onto /. I already tried succesfully to overlay /etc with a directory named /data/etc by adding these lines to the /etc/fstab : /dev/mmcblk0p1 /data auto defaults 1 2 overlay /etc overlay x-systemd.requires=/data,lowerdir=/etc,upperdir=/data/etc,workdir=/data/work/etc 0 0 This is working, but the overlay is mounted after systemd has already launch its sevices. So the network configuration for example is the one in the uImage and not the one in my user filesystem. I'd like to mount the overlay before lauching systemd, just after / is mounted. I have understood that at startup, the system creates a first memory space in ram and then extracts the cpio image in it. Then / is mounted there and the system launches the first program : systemd:/sbin/init with the PID 1. Is my understanding right ? I have read lots of article and Q&A website but I still do not understand where I have to make the changes to perform my overlay at boot time. What are the files that contains the mount / operation ?

I'm new to linux an I installed armbian to an sd card and everything works fine. The SD-Card is 64GB. Then I installed docker.io, docker-compose and portainer, nothing else. When I check for disk space with lsblk: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59.5G 0 disk ├─mmcblk0p1 179:1 0 512M 0 part /boot └─mmcblk0p2 179:2 0 58.4G 0 part / mmcblk1 179:32 0 14.6G 0 disk mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk zram0 254:0 0 50M 0 disk /var/log zram1 254:1 0 929.4M 0 disk [SWAP] Then with df: # df -h Filesystem Size Used Avail Use% Mounted on udev 796M 0 796M 0% /dev tmpfs 186M 8.0M 178M 5% /run /dev/mmcblk0p2 58G 2.2G 55G 4% / tmpfs 930M 0 930M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 930M 0 930M 0% /tmp /dev/mmcblk0p1 511M 59M 453M 12% /boot /dev/zram0 49M 7.0M 38M 16% /var/log overlay 58G 2.2G 55G 4% /var/lib/docker/overlay2/b28da5a318945ac7ae1d17d26a635edb9a662c6116dea37fb4f6c13e1c76d7d2/merged tmpfs 186M 0 186M 0% /run/user/0 Why are there 2 remaining 55 GB (/dev/mmcblk0p2 and the overlay filesystem)? Does this mean that I can only use the 55 GB space on the /var/lib/docker/overlay2/.../merged folder?

I'm trying to use the overlayroot package in ubuntu 24.04 to boot into a read only root filesystem but have a writable overlay. Everything I see online says to update the /etc/overlayroot.conf file and then reboot. Here's what I have configured:

overlayroot=tmpfs:recurse=1,debug=1
overlayroot_cfgdisk="disabled"

But when I reboot and log in via SSH my / isn't overlayfs and there seems to be no logs indicating what the issue might be. The only thing I can think of is if the fact I'm doing this in EC2 making a difference.

I have read-only root file system, protected with dm-verity and clean read-write user data storage. Nevertheless, I need to make a tiny set of files on rootfs which require persistent storage **modifiable**. As far as I know, the common approach for this is to use **unionfs** like file-systems, for example overlayfs . The problem with overlayfs, is that it seems it doesn't provide file-level granularity. What do I mean: for example if I want to make **/etc/resolv.conf** modifiable, I need to mount entire **/etc/** folder accordingly. mount -t overlay overlay -o lowerdir=/etc,upperdir=/opt/storage/etc-up,workdir=/opt/storage/etc-wd,noexec /etc I tried then to use file bind mounts instead of overlayfs, to overcome this, so the idea was to copy target file to read write storage at the boot time, and then bind-mount to original place. However it seems in some cases, for example user add, software also tries to **create** some temporary files in /etc folder (f.e. lock files), so that didn't work for me (file creation of course failed because original rootfs mounted ro) I'm wondering if there is a solution which will help me to do what I want. The requirements could be summarized as: - The most of the rootfs is left forever readonly (implemented already, the rootfs shall be mounted ro) - I can statically define at the image build time that file1, file2 ... file_n are excluded from this "forever-readonly" data list. - I can define that new files can be created in folder1, folder2 ... folder_n

I'm learning about the linux overlay file system and I'm having a problem that's beyond my knowledge. Can anyone explain the technical rationale behind this?

mkdir ./{merged,work,upper,lower}
echo "message from lower" >> ./lower/h

sudo mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged
# copy lower/h on write, and will save to lower/h
echo "message from merged" >> ./merged/h

# check files content: merged/h and upper/h have same content
cat ./lower/h
cat ./merged/h
cat ./upper/h

# this command show merged/h and lower/h have same inode, why isn't upper/h and merged/h have same inode
stat ./lower/h ./upper/h ./merged/h

I think merged/h and upper/h should have the same inode, and lower with different inodes. However, this is not the case with the above experimental results

I create a overlayfs by this:

-sh
sudo mount -t overlay overlay -olowerdir=lower1:lower2,upperdir=upper,workdir=worker merge

1. Can I just copy the files to the upper directory or delete the files in it? 2. When I copy a new file (same name in lower2) to lower1, how can I update it in merge? Now, I update it by following steps, is this legal? 1. xx file in lower2/dir/xx 2. cp xx (new file) to lower1/dir/xx 3. rm merge/dir/xx 4. rm upper/dir/xx 5. merge/dir/xx file is same with lower1/dir/xx

I tried to mount an external storage device (a usb flash drive) with overlay (as the lowerdir the usb and as upper a temporary ramdisk) mkdir /data mkdir /data/lower mkdir /data/rw mkdir /data/root Then creating the ramdisk mount -t tmpfs none /data/rw mkdir /data/rw/upper mkdir /data/rw/work I mounted the usb device mount -t vfat /dev/sdb1 /data/lower To finally use overlay : mount -t overlay -o lowerdir=/data/lower,upperdir=/data/rw/upper,workdi=/data/rw/work none /data/root Which give me the folowwing error > wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error > overlayfs: filesystem on '/data/lower' not supported But according to the documentation > The lower filesystem can be any filesystem supported by Linux and does not need to be writable Is there a link with automount and if so how I can fix it ?

I am trying to give all Users on a system their own writable copy of a root-owned directory, and OverlayFS sounds like the tool for the job, but I am finding it not as straightforward as it sounded at first. First, the setup: > mkdir upper work merged merged-user > sudo mkdir -p lower/path/to > sudo touch lower/path/to/file > ls -l drwx------ 2 user group 4096 Aug 10 00:00 merged drwx------ 2 user group 4096 Aug 10 00:00 merged-user drwxr-xr-x 3 root root 4096 Aug 10 00:00 lower drwx------ 2 user group 4096 Aug 10 00:00 upper drwx------ 2 user group 4096 Aug 10 00:00 work The goal at the end is to allow User user to write to any directory or path in the merged or merged-user mount point. First attempt, with mount: > sudo mount -t overlay overlay -o "lowerdir=$PWD/lower,upperdir=$PWD/upper,workdir=$PWD/work" merged > ls -l merged/path/to total 4 -rw-r--r-- 1 root root 5 Aug 10 00:00 file > echo me > merged/path/to/file sh: merged/path/to/file: Permission denied I get it; at the kernel level, OverlayFS isn't touching the permissions, so the merged directory doesn't have the permissions setup I would like. Enter fuse-overlayfs : fuse-overlayfs -o "lowerdir=lower,upperdir=upper,workdir=work,squash_to_uid=$(id -u)" merged-user > ls -la merged-user/ total 8 drwx------ 3 user group 4096 Aug 10 00:00 . drwxr-xr-x 3 root root 4096 Aug 10 00:00 path > echo me > merged-user/path/to/file sh: merged-user/path/to/file: Permission denied Still permission denied, even with the squash_to_uid option. Am I missing some other parameter that would enabled merged or merged-user to appear as the User's own directories?

I know about the overlayfs that it treats the lower directory as a read-only and copy_up when we want to modify the lower file. So, is there any way to modify the lower filesystem so we can copy the modified file to the lower directory? From the [kernel docs](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt) : > Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.

I have quite a bit complex setup. I'm running https://github.com/demostanis/demolinux . The root filesystem is made out of an overlayfs between a btrfs read-only subvolume and a read-write btrfs subvolume, with a second overlayfs on top, made out of the previous one and a tmpfs. simplified, in the initramfs:

mount -o lowerdir=ro-system,upperdir=rw-system /overlay1
mount -o lowerdir=/overlay1,upperdir=tmpfs /overlay2
switch_root /overlay2

Since I also want it this way at work, I run a VM, stored on a networked filesystem (NFS). But for some reason, the NFS setup there is very unreliable (which is very unlikely to change), so it often disconnects for a few minutes, and comes back. But when it's back, my VM acts weird! I can't write or read files anymore, since every I/O operation results in "Input/output error"s, or segfaults, except for stuff in kernel cache. Since I don't want to reboot everytime this happens, I'm looking for a way to fix it. Maybe automatically redoing the overlayfs when something fails? Any other idea? Thanks

I want to load docker image without dockerd. (like docker load -i image.tar ) I see that when I load docker image there are files that added to only 2 directories: overlay2,image How can I set the desire files there from my image.tar without running docker/dockerd? (I just want to understand the Docker filesystem layout. So I looking for a way to simulate the loading image in a shell script)