-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to configure container ... overlay mount for '/' failed #776
Comments
The problem for overlay mounts affects all directories that are non-leaf mount points (i.e., directories below which there is another mount point somewhere). This means that for most people a suitable workaround should be something like I have reported an Ubuntu bug in their tracker. |
If directory modes for /foo and /foo/bar are given, and these two modes are the same, and /foo/bar is not already a mountpoint, there is no point in doing something for /foo/bar: The directory mode for /foo will apply to /foo/bar as well anyway. Avoiding these useless nested mounts is especially good for overlay mounts: Overlayfs complains (in the kernel log) if we first use .../temp/foo as upper directory of an overlayfs instance and then use .../temp/foo/bar as an upper directory of another overlayfs instance as well. The message says that we should not create overlayfs instances with overlapping upper directories. With the change of this commit we do this less often, we only create overlapping overlayfs mounts in the following two situations: a) if /foo and /foo/bar are both overlays and on different file systems, but currently this fails anyway due to #776; and b) if /foo is an overlay, /foo/bar is something else, and /foo/bar/child is an overlay again. However, so far this has worked without problems. This is likely because if we use both .../temp/foo and .../temp/foo/bar/child as upper directories for two overlayfs instances, we will never actually access the bar/child directory through the former instance. Each actual directory in the upper directory is accessed only via a single overlayfs instance.
For those affected by this issue, you can install BenchExec 3.25 and fuse-overlayfs 1.10 or newer (available for example in Ubuntu 24.04) and then the default directory works again without the need for |
On Ubuntu 18.04 with kernel 4.15.0-159 and on Ubuntu 20.04 with kernel 5.4.0-89-generic (and likely similarly recent versions) BenchExec fails by default with the error
Avoiding the use of overlay for
/
(e.g., with--read-only-dir /
) indeed makes it work. Overlay mode for other directories works.According to the changelog (here for 18.04) the respective patch is very likely the one named "ovl: prevent private clone if bind mount is not allowed", which is originally here and was backported to older kernels as well.
We have to investigate what exactly is the condition that makes it fail for
/
and lets it work for other directories, and then consider either reporting this as a regression or find a workaround. As the patch is a security fix (announcements from Ubuntu, Debian), we might need the latter.The text was updated successfully, but these errors were encountered: