Unable to mount virtual filesystem(i.e. procfs)

[AlexTalker]

Context

This might not only be related to procfs but my current application of sysbox relies on being able to, at least:

# mount -t proc proc /any/other/path

inside the container. Initially, I tested this on aarch64 by building latest(for May 2026) version from git and got something akin to -ENOENT,
even when following this minimal test manually ( https://github.com/nestybox/sysbox/blob/master/tests/syscall/mount/mount-procfs.bats ).
Then I switched to x86_64 and got the similar results. This prompted me to update slightly outdated edition of Manjaro Linux to the latest packages and also install new LTS kernel(both previous scenarious happened on 6.6 LTS kernel), after which the Apline image from the tests started mounting the filesystem as expected:

# docker run -it --runtime sysbox-runc --rm ghcr.io/nestybox/alpine-docker-dbg:latest /bin/sh
/ # mkdir /tmp/t
/ # mount -t proc proc /tmp/t
/ #

But apparently, the true caveat was hidden in me using the manjarolinux/base:latest since the beginning, since an error remains:

# docker run -it --runtime sysbox-runc --rm manjarolinux/base:latest /bin/sh
sh-5.3# mkdir /tmp/t
sh-5.3# mount -t proc proc /tmp/t
mount: /tmp/t: permission denied.
       dmesg(1) may have more information after failed mount system call.

However, using busybox version of mount functions as needed(and Alpine uses busybox too IIRC):

# docker run -it --runtime sysbox-runc --rm manjarolinux/base:latest /bin/sh
sh-5.3# pacman -Sy busybox
:: Synchronizing package databases...
 core                                                        153.6 KiB  95.0 KiB/s 00:02 [###################################################] 100%
 extra                                                         8.8 MiB  5.80 MiB/s 00:02 [###################################################] 100%
resolving dependencies...
looking for conflicting packages...

Packages (1) busybox-1.36.1-4

Total Download Size:   0.83 MiB
Total Installed Size:  1.76 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 busybox-1.36.1-4-x86_64                                     852.2 KiB  2.32 MiB/s 00:00 [###################################################] 100%
(1/1) checking keys in keyring                                                           [###################################################] 100%
(1/1) checking package integrity                                                         [###################################################] 100%
(1/1) loading package files                                                              [###################################################] 100%
(1/1) checking for file conflicts                                                        [###################################################] 100%
:: Processing package changes...
(1/1) installing busybox                                                                 [###################################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Cleaning up package cache...
sh-5.3# mkdir /tmp/t
sh-5.3# busybox mount -t proc proc /tmp/t
sh-5.3#

Slightly poking with strace reveals the "obvious" difference, since busybox uses classical mount syscall:

...
stat("proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
mount("proc", "/tmp/t", "proc", MS_SILENT, NULL) = 0
exit_group(0) 
...

But stock mount uses new fancy syscalls and fails:

...
fsopen("proc", FSOPEN_CLOEXEC)          = -1 EPERM (Operation not permitted)
geteuid()                               = 0
newfstatat(AT_FDCWD, "/tmp/t", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_NO_AUTOMOUNT) = 0
write(2, "mount: ", 7)                  = 7
write(2, "/tmp/t: permission denied.", 26) = 26
write(2, "\n", 1)                       = 1
write(2, "       dmesg(1) may have more in"..., 74) = 74
...

Hence the question is when this syscall compatibility issue will be resolved and if I can be of any help with that? =)

Environment

# docker --version
Docker version 29.4.1, build 055a478ea9
# sysbox-runc --version
sysbox-runc
	edition: 	Community Edition (CE)
	version: 	0.7.0
	commit: 	ff3aaede52feae6ed00f59be152dc7ea473991de
	built at: 	Wed May 13 10:08:34 PM MSK 2026
	built by: 	
	oci-specs: 	1.1.0+dev
# uname -a
Linux alx-pc 6.18.26-1-MANJARO #1 SMP PREEMPT_DYNAMIC Thu, 30 Apr 2026 17:30:39 +0000 x86_64 GNU/Linux

[AlexTalker]

@ctalledo Sorry to bother with a possible duplicate but I just felt like it could be appropriate to make a dedicated issue with all the searcheable context in the main repo so here it is.

I think the issue is relevant to the comment in #973 (comment) and maybe nestybox/sysbox-fs#96 but its nighttime for me already and I'll delay figuring out the correlation between fsopen and open_tree etc for a later date =)

Just would appreciate any feedback on this and if I could somehow assist with closing the compatibility gap =)