We’re rewarding the question askers & reputations are being recalculated! Read more.
24

The workdir option is required, and used to prepare files before they are switched to the overlay destination in an atomic action (the workdir needs to be on the same filesystem as the upperdir). Source: http://windsock.io/the-overlay-filesystem/ I would hazard a guess that "the overlay destination" means upperdir. So... certain files (maybe "whiteout"...


11

If it's a case of tail not working at all, then it could be because your liveCD is using the overlayfs filesystem, which has a bug regarding notifications of modified files. You could try to move the log to another filesystem, such as /tmp if the application creating the log has an option to do so. You could also carry out your test in /tmp instead of your ...


6

short answer: yes long answer: from the sections "Upper and Lower" and "Multiple lower layers": "...The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem even be another overlayfs. ..."


6

This probably has to do with the fact that a for a ready only mount (which is probably the case for a clonezilla usb key) a workdir is not needed and is left blank in the OverlayFS mount config. Thus the notice is saying that it is missing, but in this case that is nothing to worry about. You can just go ahead and clone your partition!


5

One solution could be to use an initramfs to mount the rootfs with overlayfs. You can have a look how it is done on the Raspberry Pi or, if not using an ARM device, at the overlayroot Ubuntu package


4

Grepping for "depth" in /usr/src/linux/fs/overlayfs finds that it's just a simple checking of the current stacking depth against FILESYSTEM_MAX_STACK_DEPTH. Search for that in the include files finds that FILESYSTEM_MAX_STACK_DEPTH is defined to be 2 in /usr/src/linux/include/linux/fs.h. The comment says Maximum number of layers of fs stack. Needs to be ...


3

The challenge of mounting root as overlayfs has been solved. Briefly, the 'lower', 'work' and 'upper' directories should be moved to the 'merge' dir. However, you should consider: 1) There is no need to do something if the 'lower' directory is present as a disk image. Just mounting it. If not, create tmpfs mount point on it and copy all needed files over ...


3

https://github.com/torvalds/linux/commit/e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9 /* * procfs isn't actually a stacking filesystem; however, there is * too much magic going on inside it to permit stacking things on * top of it */ s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; This might not be a very informative answer, but the ...


3

The folders in /mnt/config/.data and /mnt/config/.work contain your changes. You can move them out of the way to create new ones. Unmount the overlay and remount it with a clean upper dir: umount /etc mv /mnt/config/.data /mnt/config/.data.old mv /mnt/config/.work /mnt/config/.work.old mkdir /mnt/config/.data mkdir /mnt/config/.work mount -t overlay ...


2

I just downloaded the stable version and had the same error as you. I tried to used a previous version, it displayed the message but immediately continued. I suspect we have some incompatibility with the latest version.


2

The kernel exposes the (full list of) mount options via /proc/mounts. For overlayfs, this includes the lowerdir and upperdir options: $ cd /tmp $ mkdir lower upper overlay $ sudo mount -t overlayfs -o lowerdir=/tmp/lower,upperdir=/tmp/upper none /tmp/overlay $ tail -n 1 /proc/mounts none /tmp/overlay overlayfs rw,relatime,lowerdir=/tmp/lower,upperdir=/tmp/...


2

This answer is based on my own experience, but not with embedded devices. Maybe it's useful to others who stumble on this setup -- you should adapt it to your specific circumstances, or at least hopefully learn a thing or two from it. A simple method is to hijack the place when the root filesystem gets mounted (in initramfs, otherwise hijack the init ...


2

enable the kernel module with modprobe overlay alternatively add overlay to systemd : echo "overlay" > /etc/modules-load.d/overlay.conf and restart


2

Yes, you can specify the size of a tmpfs using the size mount option, or the nr_blocks option. With size, you can specify the size in bytes (or kibibytes, or mebibytes, or gibybytes), or as a percentage of installed memory. The size of a tmpfs can be changed on remount, after the initial setup, so with overlayroot you could reduce the size of the file ...


2

The file /etc/mtab is written by the mount and umount commands. Keeping it accurate requires a bit of work because they can only update /etc/mtab if that file is available and writable. For the usual case where /etc is mounted read-write at some point during boot, distributions set up a script that rewrite /etc/mtab during startup, as soon as the root ...


2

I was sure, that module is statically compiled in kernel, but I was wrong: CONFIG_OVERLAY_FS=m. After adding the overlay module to initrd everything works fine.


2

I tried to chroot to the merged directory. The result was just as expected: I had rw rootfs, the only thing I missed was virtual kernel filesystems. So after mounting the overlay I did the following: TARGETDIR="/tmp/usbstick/merged" mount -t proc proc $TARGETDIR/proc mount -t sysfs sysfs $TARGETDIR/sys mount -t devtmpfs devtmpfs $TARGETDIR/dev mount -t ...


2

An attempt at an online solution, but its not quite there. The setup (in e.g. /tmp directory, as root): LOWER=$HOME mkdir u1 w1 o1 O mount -t overlay overlay -o lowerdir=$LOWER,upperdir=u1,workdir=w1 o1 mount --bind o1 O Then you can work in O directory, which is an overlay over $LOWER. When you want to do the snapshot: mkdir u2 w2 o2 mount -t overlay ...


2

Another offline solution I've come up with is using rdiffdir to create a patch with the overlay mounted, then unmount and apply it. This solution requires the intermediate step of storing the patch somewhere in the meantime (either on disk or in a ramdisk/tmpfs).


1

I have found the overlayfs-tools project which implements a useful set of tools (diff, merge and vacuum). It requires the overlay to be unmounted so is an offline-only solution. It is a good proof-of-concept but I wouldn't rely on it in its current state as it has only a single maintainer and no activity for several years.


1

Once a file is open, it stays open until the process closes it. Reading and writing from a file don't care whether the file is still available under its original name. The file may have been renamed, deleted, shadowed… it's still the same file. If you open a file /somewhere/somefile then mount a filesystem at /somewhere, then after that point /somewhere/...


1

I ran into the exact same problem (trying to do the exact same thing: a read-only base system for a PXE boot environment). The behavior I'm seeing exactly matches that in this Ubuntu bug report. I cannot write changes to existing files, but I can delete them (but they're preserved in the lower filesystem... with the upper layer just recording their absence) ...


1

Transform the input into the required syntax and splice it into the command line with a command substitution. dirs_with_photos="$(<~/dirs_with_photos.txt tr '\n' :)" if [ -n "$dirs_with_photos" ]; then unionfs-fuse "${dirs_with_photos%:}" /photos fi With mount_unionfs you need to issue one mount command per directory. You can use a loop around the ...


1

There isn't really a notion of “what occupies the space” in an overlay filesystem. Each branch of the union has its own space occupation. Run du on both branches. If it's getting more full, the read-write branch is the culprit. Since the overlay mount shadows its branches (/root_ro and /root_rw are hidden by the mount on /), you need to gain access to the ...


1

Unmount the overlay filesystem, and then mount it somewhere else and check it using du. If I understand them correctly, that should let you see what's in it.


1

You could take a look at the project squashmount. It mounts a directory with both a squashfs and an autofs/overlay/overlayfs system to allow for squashing ro access as well as write access. Completely configurable on how much change requires re-squashing, its a nice to use for database storage, repos spools, etc.


1

What kernel are you using? it seems that a bug was introduced in kernel 4.2: https://github.com/coreos/rkt/issues/1537


1

On Ubuntu sticks, look for a file called casper-rw while the stick is not booted. That file should contain the changes.


1

You can write to the underlying directory by not using the created overlay to access the file (the directory "X" in this case). Do it with: echo 'This is a modification' >> L/lower


1

I don't know if you noticed, but your second mount is incorrect: -m g:0:2000000:65536 should be -m g:0:200000:65536. Your command has an extra 0. I followed your steps and I couldn't find any error: root@clone-newuser:/home/test# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=target.work overlay target root@clone-newuser:/home/test# runuser - ...


Only top voted, non community-wiki answers of a minimum length are eligible