https://bugzilla.kernel.org/show_bug.cgi?id=218336 Bug ID: 218336 Summary: mount(2) doesn't document ENOSPC when /proc/sys/fs/mount-max is exceeded Product: Documentation Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: man-pages Assignee: documentation_man-pages@xxxxxxxxxxxxxxxxxxxx Reporter: smcv@xxxxxxxxxxxxx Regression: No When setting up mount points in a new mount namespace, if /proc/sys/fs/mount-max is exceeded, mount(2) will fail with ENOSPC. This isn't documented in mount(2) as a possible error result. In this situation, the error message "No space left on device" from strerror() is misleading: usually all of the user's filesystem devices will have plenty of space. The actual problem is that an essentially arbitrary anti-denial-of-service limit, orthogonal to how much space exists on any particular device, has been exceeded. For example, this could easily happen when running Flatpak, which creates new user and mount namespaces using the bubblewrap tool: $ echo 50 | sudo tee /proc/sys/fs/mount-max $ flatpak run org.gnome.Platform//45 bwrap: Failed to mount tmpfs: No space left on device error: ldconfig failed, exit status 256 I'm going to send a PR to bubblewrap to make it special-case ENOSPC and display a clearer error message in this case. It would be helpful if mount(2) indicated ENOSPC as a possible error here, so that maintainers of projects like bubblewrap could make sure to allow for it. https://github.com/ValveSoftware/steam-runtime/issues/637 is a real-world report of this happening in Steam's Steam Linux Runtime container framework, which is very similar to Flatpak. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
