github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #6450] Crash when mountinfo contains line over 4096 bytes #3278

New issue

Open

opened 2026-05-05 09:53:10 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 09:53:10 -06:00

Owner

Originally created by @warptozero on GitHub (Aug 25, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6450

Description

Firejail crashes with Error: cannot read /proc/self/mountinfo when an overlayfs is mounted with a lot of lowerdirs.

Steps to Reproduce

Use the following fish script to create and mount 100 overlay directories
Run firejail --noprofile bash

overlayfs_test.fish

#!/usr/bin/fish

sudo umount mnt &>/dev/null

rm -r lower upper
mkdir -p lower upper work mnt

for x in (seq 0 100)
    set -l d (string repeat -n 30 d)
    mkdir -p "lower/$d$x"
    touch "lower/$d$x/file_$x"
end

set dirs (fd -td -d1 . lower/ | path normalize)
set lower (string join --no-empty -- ',lowerdir+=' $dirs)

set cmd mount -t overlay overlay -o lowerdir+=$lower,upperdir=upper,workdir=work mnt
echo $cmd
sudo $cmd
tree mnt
cat /proc/self/mountinfo | wc -L

Note that this uses the newer lowerdir+ syntax to add lowerdirs one by one, which is only supported since kernel version 6.7 or 6.8.

Additional context

It seems to be related to a 4096 byte limit somewhere and not the amount of lowerdirs.

When util-linux in switched to the new kernel mount API with v2.39 the normal mount syntax of appending lowerdirs with lowerdir=d1:d2:d... stopped working for lines longer then 256 bytes. This is why the newer lowerdir+ option is needed.
The old API can still be enabled with LIBMOUNT_FORCE_MOUNT2=always and is limited to a longer option length of max 4096 bytes.
Using the newer lowerdir+ syntax allows to create a much longer entry in /proc/self/mountinfo then was previously possible.

See https://github.com/util-linux/util-linux/issues/2287 and https://github.com/util-linux/util-linux/issues/1992#issuecomment-1486475153.

Environment

Void Linux x86_64 with kernel 6.10.6_1
Firejail version 0.9.72

Compile time support

	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file transfer support is enabled
	- firetunnel support is disabled
	- IDS support is disabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
I have performed a short search for similar issues (to avoid opening a duplicate).

Log

Output of env LC_ALL=C firejail --noprofile bash

Parent pid 23279, child pid 23280
Error: cannot read /proc/self/mountinfo
Error: proc 23279 cannot sync with peer: unexpected EOF
Peer 23280 unexpectedly exited with status 1

Output of env LC_ALL=C firejail --debug --noprofile bash

Building quoted command line: 'bash'
Command name #bash#
DISPLAY=:0 parsed as 0
Using the local network stack
Parent pid 3458, child pid 3459
Initializing child process
Host network configured
PID namespace installed
Mounting tmpfs on /run/firejail/mnt directory
Creating empty /run/firejail/mnt/seccomp directory
Creating empty /run/firejail/mnt/seccomp/seccomp.protocol file
Creating empty /run/firejail/mnt/seccomp/seccomp.postexec file
Creating empty /run/firejail/mnt/seccomp/seccomp.postexec32 file
Mounting /proc filesystem representing the PID namespace
Basic read-only filesystem:
Error: cannot read /proc/self/mountinfo
Error: proc 3458 cannot sync with peer: unexpected EOF
Peer 3459 unexpectedly exited with status 1

Originally created by @warptozero on GitHub (Aug 25, 2024). Original GitHub issue: https://github.com/netblue30/firejail/issues/6450  ### Description Firejail crashes with ```Error: cannot read /proc/self/mountinfo``` when an overlayfs is mounted with a lot of lowerdirs. ### Steps to Reproduce 1. Use the following fish script to create and mount 100 overlay directories 2. Run ```firejail --noprofile bash``` <details> <summary>overlayfs_test.fish</summary> ``` #!/usr/bin/fish sudo umount mnt &>/dev/null rm -r lower upper mkdir -p lower upper work mnt for x in (seq 0 100) set -l d (string repeat -n 30 d) mkdir -p "lower/$d$x" touch "lower/$d$x/file_$x" end set dirs (fd -td -d1 . lower/ | path normalize) set lower (string join --no-empty -- ',lowerdir+=' $dirs) set cmd mount -t overlay overlay -o lowerdir+=$lower,upperdir=upper,workdir=work mnt echo $cmd sudo $cmd tree mnt cat /proc/self/mountinfo | wc -L ``` </details> Note that this uses the newer `lowerdir+` syntax to add lowerdirs one by one, which is only supported since kernel version 6.7 or 6.8. ### Additional context It seems to be related to a 4096 byte limit somewhere and not the amount of lowerdirs. - When util-linux in switched to the new kernel mount API with v2.39 the normal `mount` syntax of appending lowerdirs with `lowerdir=d1:d2:d...` stopped working for lines longer then 256 bytes. This is why the newer `lowerdir+` option is needed. - The old API can still be enabled with `LIBMOUNT_FORCE_MOUNT2=always` and is limited to a longer option length of max 4096 bytes. - Using the newer `lowerdir+` syntax allows to create a much longer entry in `/proc/self/mountinfo` then was previously possible. See https://github.com/util-linux/util-linux/issues/2287 and https://github.com/util-linux/util-linux/issues/1992#issuecomment-1486475153. ### Environment - Void Linux x86_64 with kernel 6.10.6_1 - Firejail version 0.9.72 <details> <summary>Compile time support</summary> ``` - always force nonewprivs support is disabled - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - D-BUS proxy support is enabled - file transfer support is enabled - firetunnel support is disabled - IDS support is disabled - networking support is enabled - output logging is enabled - overlayfs support is disabled - private-home support is enabled - private-cache and tmpfs as user enabled - SELinux support is disabled - user namespace support is enabled - X11 sandboxing support is enabled ``` </details> ### Checklist - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). ### Log <details> <summary>Output of <code>env LC_ALL=C firejail --noprofile bash</code></summary> ``` Parent pid 23279, child pid 23280 Error: cannot read /proc/self/mountinfo Error: proc 23279 cannot sync with peer: unexpected EOF Peer 23280 unexpectedly exited with status 1 ``` </details> <details> <summary>Output of <code>env LC_ALL=C firejail --debug --noprofile bash</code></summary> ``` Building quoted command line: 'bash' Command name #bash# DISPLAY=:0 parsed as 0 Using the local network stack Parent pid 3458, child pid 3459 Initializing child process Host network configured PID namespace installed Mounting tmpfs on /run/firejail/mnt directory Creating empty /run/firejail/mnt/seccomp directory Creating empty /run/firejail/mnt/seccomp/seccomp.protocol file Creating empty /run/firejail/mnt/seccomp/seccomp.postexec file Creating empty /run/firejail/mnt/seccomp/seccomp.postexec32 file Mounting /proc filesystem representing the PID namespace Basic read-only filesystem: Error: cannot read /proc/self/mountinfo Error: proc 3458 cannot sync with peer: unexpected EOF Peer 3459 unexpectedly exited with status 1 ``` </details>

gitea-mirror added the

bug

label 2026-05-05 09:53:10 -06:00

gitea-mirror commented

2026-05-05 09:53:13 -06:00

Author

Owner

@warptozero commented on GitHub (Aug 26, 2024):

Note that this is not about overlayfs support in firejail, but failing to start when an existing overlayfs is mounted. This might also happen with other mounts that create a very long line in mountinfo.

Unfortunately x-* options don't show up in mountinfo so I haven't found a way to test this yet.

@warptozero commented on GitHub (Aug 26, 2024): Note that this is not about overlayfs support in firejail, but failing to start when an existing overlayfs is mounted. This might also happen with other mounts that create a very long line in mountinfo. Unfortunately `x-*` options don't show up in mountinfo so I haven't found a way to test this yet.

gitea-mirror commented

2026-05-05 09:53:13 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 26, 2024):

# Actually 255 bytes for almost everything except of FAT32, but you know, trailing-nul-byte, some implementations, ...
max_filename="$(head -c 254 < /dev/zero | tr '\0' 'x')"
# (254 "x" + 1 "/") * 16 = 4080; MAX_PATH is 4096
very_long_path="$(for _ in {1..16}; do echo -n "/$max_filename"; done)"
# Create it in a tmpfs, in the worst case you need to hard-reboot but it will not break the next boot if there is some buggy tool.
mkdir -p /tmp$very_long_path
mount -o bind /tmp$very_long_path /tmp$very_long_path
# Test firejail
umount /tmp$very_long_path
rm -rf /tmp/xxx<TAB>

@rusty-snake commented on GitHub (Aug 26, 2024): ```bash # Actually 255 bytes for almost everything except of FAT32, but you know, trailing-nul-byte, some implementations, ... max_filename="$(head -c 254 < /dev/zero | tr '\0' 'x')" # (254 "x" + 1 "/") * 16 = 4080; MAX_PATH is 4096 very_long_path="$(for _ in {1..16}; do echo -n "/$max_filename"; done)" # Create it in a tmpfs, in the worst case you need to hard-reboot but it will not break the next boot if there is some buggy tool. mkdir -p /tmp$very_long_path mount -o bind /tmp$very_long_path /tmp$very_long_path # Test firejail umount /tmp$very_long_path rm -rf /tmp/xxx<TAB> ```

gitea-mirror commented

2026-05-05 09:53:14 -06:00

Author

Owner

@warptozero commented on GitHub (Aug 26, 2024):

Thanks, I could reproduce this with a long path length.

Looking at the code a quick fix is to simply increase MAX_BUF in mountinfo.c. xargs --show-limits reports the actually used max command buffer as 131072 (128 * 1024). So to be able to handle a mount command near this size I had to set MAX_BUF to 129 * 1024.

Starting a firejail with a long mountinfo line of 131112 bytes takes around 241ms instead of the normal 6.4ms without it mounted. So this probably needs a better solution in the parser.

@warptozero commented on GitHub (Aug 26, 2024): Thanks, I could reproduce this with a long path length. Looking at the code a quick fix is to simply increase `MAX_BUF` in [mountinfo.c](https://github.com/netblue30/firejail/blob/fecd25d699b91c16f26d313bb783950c9f706fcd/src/firejail/mountinfo.c#L29). `xargs --show-limits` reports the actually used max command buffer as 131072 (128 * 1024). So to be able to handle a mount command near this size I had to set `MAX_BUF` to 129 * 1024. Starting a firejail with a long mountinfo line of 131112 bytes takes around 241ms instead of the normal 6.4ms without it mounted. So this probably needs a better solution in the parser.

gitea-mirror commented

2026-05-05 09:53:15 -06:00

Author

Owner

@tsankuanglee commented on GitHub (Apr 16, 2025):

I'm seeing the same error as well.

$ env LC_ALL=C firejail --noprofile bash


firejail version 0.9.74

Parent pid 177653, child pid 177654
Error: cannot read /proc/self/mountinfo
Error: proc 177653 cannot sync with peer: unexpected EOF
Peer 177654 unexpectedly exited with status 1

I have a few Docker containers running. Docker's overlays are typically very long (with its many layers and each using hashes in the path) for bind mounts, and can easily go over the current limit.

If I bring down the containers, those long mountinfo lines are gone, and firejail works.

Some ideas:

If increasing MAX_BUF's performance impact is a one-time 234.6 ms, can we consider this fix?
Or is it possible to ignore any lines with docker or podman in them? The keywords happen early in the line. Here's one example (this is an image built upon tensorflow notebook container):

overlay on /var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/HJDQ6AV5NIJ4PDEWBPTNO3LHTB:/var/lib/docker/overlay2/l/44R4LD6NLEJSELG2JDYDFKAAGI:/var/lib/docker/overlay2/l/ILODEOYBNRKQBHIKGTPZALYXUN:/var/lib/docker/overlay2/l/74FMQ5KDNYXC7R3IXWU7DGOPKN:/var/lib/docker/overlay2/l/ALCYSO3BC5VILKEYOGNSY2TBCX:/var/lib/docker/overlay2/l/ITEDMGNV5UFWYWVBWINH22JG63:/var/lib/docker/overlay2/l/GDPXQF2XHHN3JDEHWXRYOH4BHF:/var/lib/docker/overlay2/l/4O2TYCDBFPBF5YPFPI77PKKYBW:/var/lib/docker/overlay2/l/36OAYB7Z6NTMSY6O3U7IQLIZHK:/var/lib/docker/overlay2/l/KX3MQ7FDX25RDMQKACLAEV66LU:/var/lib/docker/overlay2/l/L5YYT4XKHI2SARQGCL74FFPXLO:/var/lib/docker/overlay2/l/NU4EYEZNS2GS2OB6FBZEYBWKJG:/var/lib/docker/overlay2/l/FACOWVNEZHOBBJSDXDNA2MCSNU:/var/lib/docker/overlay2/l/2ZRR5RAYI5WDOO4E534HOT4MZ5:/var/lib/docker/overlay2/l/TYE23TN3GM4BWJQDX3DJODK34U:/var/lib/docker/overlay2/l/CDNC76RN5ZJ75LURGFTOLOE5AV:/var/lib/docker/overlay2/l/WL4DMVUKOXSJ2DINQ23U4IS3EX:/var/lib/docker/overlay2/l/C2LDHQIL6HB4NNKD2XMXKWCAE2:/var/lib/docker/overlay2/l/2CRB25MABZPUV3B2F2UHEWGXG3:/var/lib/docker/overlay2/l/ZDVGENYOF4ETAW6MP4ZR5NQGYR:/var/lib/docker/overlay2/l/ZQMA5L4TKP2R4ZQGMHUEX3JLGN:/var/lib/docker/overlay2/l/URKM7DBMXJW7GBZNZNRHFZGCX2:/var/lib/docker/overlay2/l/ACUN5XCM5TMICU3PUEZPWX33IQ:/var/lib/docker/overlay2/l/EEJVC3PUTAFLYD54GIIL7GHUBF:/var/lib/docker/overlay2/l/IABCSMAEUUFJL6ZQNB2634VTLT:/var/lib/docker/overlay2/l/VH4BNER6XEB732IOOI4NM2LDPQ:/var/lib/docker/overlay2/l/MOU46RIMHOKQROEP4MUG375HKA:/var/lib/docker/overlay2/l/KVL3IMXBKWCUOJ2DR4CFOWCEJR:/var/lib/docker/overlay2/l/QSAGXNKPYHF4IYJLUY452FTPBZ:/var/lib/docker/overlay2/l/IIRU5X3QFDXMAQWMJVJ4QEOHEX:/var/lib/docker/overlay2/l/T47RGRHWWA5FR3WRWUFBH3UZFN:/var/lib/docker/overlay2/l/ZWABZDXNO77ZVW4LPCSUYWWGNV:/var/lib/docker/overlay2/l/XIAJ3CG2335CNVNXSMPDLMGCEU:/var/lib/docker/overlay2/l/DNZPCY42IL7TYIVMAG3K6AEEV3:/var/lib/docker/overlay2/l/35KM7TAPR7HXN4WSTY7QN6ECUI:/var/lib/docker/overlay2/l/A2I2J2LBIKJSGZNID7KLILJZVG:/var/lib/docker/overlay2/l/6EKQXBOH2JVJ4F4BNLLJEPNEMC:/var/lib/docker/overlay2/l/3MOO3NQ5ERBGE3TK64XXG3FNXU:/var/lib/docker/overlay2/l/MF2Z4EVMW7NUIEVPVJPC3DDCDO:/var/lib/docker/overlay2/l/UT4J7GEBPKI23GGISU6IW2NQHF:/var/lib/docker/overlay2/l/MHY2P6SE4MVMXBLZLQVSHU2RFF:/var/lib/docker/overlay2/l/5MNDOSG4PO46VJ6SICO3ZULG47:/var/lib/docker/overlay2/l/LMOUTVEXNRJSEXTIAQR7SBSRXP:/var/lib/docker/overlay2/l/MBXUP37R4FD3UT5BKWIOG3QO2G:/var/lib/docker/overlay2/l/ZTLXE7F7K5ZGBEIVMPQ7FBF3ZO:/var/lib/docker/overlay2/l/PNTRJDSIMBUKYCJNPI4SGUBTT5:/var/lib/docker/overlay2/l/3YOROAERDLAYFYGWPZDIBNGY7Q:/var/lib/docker/overlay2/l/FRWWIUOHFSO6NWSJKHSH7EWK46:/var/lib/docker/overlay2/l/MLFGGIF4DZIBNUXZ7JOPCER76Z:/var/lib/docker/overlay2/l/LREAUPAWT6NCJYZQQGE636Y7XD:/var/lib/docker/overlay2/l/GO6N47YTIQPKQOSPK2I64OS6G6:/var/lib/docker/overlay2/l/DDITNFC245QXJVFSQ4VMOBO26W:/var/lib/docker/overlay2/l/Y563JF7SQE64UWBFKMA3YAHBDJ:/var/lib/docker/overlay2/l/7I2CV2LXJILXOPBRCMVXPT2EGP:/var/lib/docker/overlay2/l/ABHZWCJO26GD4PECACQNSQXUP5:/var/lib/docker/overlay2/l/BTMVX5ZMNMKXB5TGQBFOSZLYPE:/var/lib/docker/overlay2/l/HNIT3F7XV3KEXUERE3VBHF7N5I:/var/lib/docker/overlay2/l/KFWZB2NQXZZIR7N2ZA6KQF6USF:/var/lib/docker/overlay2/l/SZS6WI5NDDSWA2JUU5OV5YHXYH:/var/lib/docker/overlay2/l/FO2HZRBKABYGPBREZDOU7K6NNK:/var/lib/docker/overlay2/l/T42424ADKKCDJ35DPQEFFGRZIJ:/var/lib/docker/overlay2/l/G5PV65Z5W3MDYOQETPLVLVR2R6:/var/lib/docker/overlay2/l/NX3D2EQQ7T4JWHDJ6N3KBQ2NFB:/var/lib/docker/overlay2/l/HEL6AEJBGKJE5VN63CKY42CBM2:/var/lib/docker/overlay2/l/DKWSBFSQA5HMF32U2Z6N7N742X:/var/lib/docker/overlay2/l/CC6EOEPOMPCXVLEXGJNHZ52KPG:/var/lib/docker/overlay2/l/AMIGATU6GGLA37IJ3AR4XYCTNN:/var/lib/docker/overlay2/l/2GAWTC7FON7I7IHQBOS6N6IJBT:/var/lib/docker/overlay2/l/R6T5ODPCJAGSQ3MGDKIE4SGDP7,upperdir=/var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/diff,workdir=/var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/work,index=off)

(hackish) Or is it possible to let users provide a custom path for mountinfo? That way, users can custom trim it.

@tsankuanglee commented on GitHub (Apr 16, 2025): I'm seeing the same error as well. ``` $ env LC_ALL=C firejail --noprofile bash firejail version 0.9.74 Parent pid 177653, child pid 177654 Error: cannot read /proc/self/mountinfo Error: proc 177653 cannot sync with peer: unexpected EOF Peer 177654 unexpectedly exited with status 1 ``` I have a few Docker containers running. Docker's overlays are typically very long (with its many layers and each using hashes in the path) for bind mounts, and can easily go over the current limit. If I bring down the containers, those long mountinfo lines are gone, and firejail works. Some ideas: 1. If increasing `MAX_BUF`'s performance impact is a one-time 234.6 ms, can we consider this fix? 2. Or is it possible to ignore any lines with `docker` or `podman` in them? The keywords happen early in the line. Here's one example (this is an image built upon tensorflow notebook container): ``` overlay on /var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/HJDQ6AV5NIJ4PDEWBPTNO3LHTB:/var/lib/docker/overlay2/l/44R4LD6NLEJSELG2JDYDFKAAGI:/var/lib/docker/overlay2/l/ILODEOYBNRKQBHIKGTPZALYXUN:/var/lib/docker/overlay2/l/74FMQ5KDNYXC7R3IXWU7DGOPKN:/var/lib/docker/overlay2/l/ALCYSO3BC5VILKEYOGNSY2TBCX:/var/lib/docker/overlay2/l/ITEDMGNV5UFWYWVBWINH22JG63:/var/lib/docker/overlay2/l/GDPXQF2XHHN3JDEHWXRYOH4BHF:/var/lib/docker/overlay2/l/4O2TYCDBFPBF5YPFPI77PKKYBW:/var/lib/docker/overlay2/l/36OAYB7Z6NTMSY6O3U7IQLIZHK:/var/lib/docker/overlay2/l/KX3MQ7FDX25RDMQKACLAEV66LU:/var/lib/docker/overlay2/l/L5YYT4XKHI2SARQGCL74FFPXLO:/var/lib/docker/overlay2/l/NU4EYEZNS2GS2OB6FBZEYBWKJG:/var/lib/docker/overlay2/l/FACOWVNEZHOBBJSDXDNA2MCSNU:/var/lib/docker/overlay2/l/2ZRR5RAYI5WDOO4E534HOT4MZ5:/var/lib/docker/overlay2/l/TYE23TN3GM4BWJQDX3DJODK34U:/var/lib/docker/overlay2/l/CDNC76RN5ZJ75LURGFTOLOE5AV:/var/lib/docker/overlay2/l/WL4DMVUKOXSJ2DINQ23U4IS3EX:/var/lib/docker/overlay2/l/C2LDHQIL6HB4NNKD2XMXKWCAE2:/var/lib/docker/overlay2/l/2CRB25MABZPUV3B2F2UHEWGXG3:/var/lib/docker/overlay2/l/ZDVGENYOF4ETAW6MP4ZR5NQGYR:/var/lib/docker/overlay2/l/ZQMA5L4TKP2R4ZQGMHUEX3JLGN:/var/lib/docker/overlay2/l/URKM7DBMXJW7GBZNZNRHFZGCX2:/var/lib/docker/overlay2/l/ACUN5XCM5TMICU3PUEZPWX33IQ:/var/lib/docker/overlay2/l/EEJVC3PUTAFLYD54GIIL7GHUBF:/var/lib/docker/overlay2/l/IABCSMAEUUFJL6ZQNB2634VTLT:/var/lib/docker/overlay2/l/VH4BNER6XEB732IOOI4NM2LDPQ:/var/lib/docker/overlay2/l/MOU46RIMHOKQROEP4MUG375HKA:/var/lib/docker/overlay2/l/KVL3IMXBKWCUOJ2DR4CFOWCEJR:/var/lib/docker/overlay2/l/QSAGXNKPYHF4IYJLUY452FTPBZ:/var/lib/docker/overlay2/l/IIRU5X3QFDXMAQWMJVJ4QEOHEX:/var/lib/docker/overlay2/l/T47RGRHWWA5FR3WRWUFBH3UZFN:/var/lib/docker/overlay2/l/ZWABZDXNO77ZVW4LPCSUYWWGNV:/var/lib/docker/overlay2/l/XIAJ3CG2335CNVNXSMPDLMGCEU:/var/lib/docker/overlay2/l/DNZPCY42IL7TYIVMAG3K6AEEV3:/var/lib/docker/overlay2/l/35KM7TAPR7HXN4WSTY7QN6ECUI:/var/lib/docker/overlay2/l/A2I2J2LBIKJSGZNID7KLILJZVG:/var/lib/docker/overlay2/l/6EKQXBOH2JVJ4F4BNLLJEPNEMC:/var/lib/docker/overlay2/l/3MOO3NQ5ERBGE3TK64XXG3FNXU:/var/lib/docker/overlay2/l/MF2Z4EVMW7NUIEVPVJPC3DDCDO:/var/lib/docker/overlay2/l/UT4J7GEBPKI23GGISU6IW2NQHF:/var/lib/docker/overlay2/l/MHY2P6SE4MVMXBLZLQVSHU2RFF:/var/lib/docker/overlay2/l/5MNDOSG4PO46VJ6SICO3ZULG47:/var/lib/docker/overlay2/l/LMOUTVEXNRJSEXTIAQR7SBSRXP:/var/lib/docker/overlay2/l/MBXUP37R4FD3UT5BKWIOG3QO2G:/var/lib/docker/overlay2/l/ZTLXE7F7K5ZGBEIVMPQ7FBF3ZO:/var/lib/docker/overlay2/l/PNTRJDSIMBUKYCJNPI4SGUBTT5:/var/lib/docker/overlay2/l/3YOROAERDLAYFYGWPZDIBNGY7Q:/var/lib/docker/overlay2/l/FRWWIUOHFSO6NWSJKHSH7EWK46:/var/lib/docker/overlay2/l/MLFGGIF4DZIBNUXZ7JOPCER76Z:/var/lib/docker/overlay2/l/LREAUPAWT6NCJYZQQGE636Y7XD:/var/lib/docker/overlay2/l/GO6N47YTIQPKQOSPK2I64OS6G6:/var/lib/docker/overlay2/l/DDITNFC245QXJVFSQ4VMOBO26W:/var/lib/docker/overlay2/l/Y563JF7SQE64UWBFKMA3YAHBDJ:/var/lib/docker/overlay2/l/7I2CV2LXJILXOPBRCMVXPT2EGP:/var/lib/docker/overlay2/l/ABHZWCJO26GD4PECACQNSQXUP5:/var/lib/docker/overlay2/l/BTMVX5ZMNMKXB5TGQBFOSZLYPE:/var/lib/docker/overlay2/l/HNIT3F7XV3KEXUERE3VBHF7N5I:/var/lib/docker/overlay2/l/KFWZB2NQXZZIR7N2ZA6KQF6USF:/var/lib/docker/overlay2/l/SZS6WI5NDDSWA2JUU5OV5YHXYH:/var/lib/docker/overlay2/l/FO2HZRBKABYGPBREZDOU7K6NNK:/var/lib/docker/overlay2/l/T42424ADKKCDJ35DPQEFFGRZIJ:/var/lib/docker/overlay2/l/G5PV65Z5W3MDYOQETPLVLVR2R6:/var/lib/docker/overlay2/l/NX3D2EQQ7T4JWHDJ6N3KBQ2NFB:/var/lib/docker/overlay2/l/HEL6AEJBGKJE5VN63CKY42CBM2:/var/lib/docker/overlay2/l/DKWSBFSQA5HMF32U2Z6N7N742X:/var/lib/docker/overlay2/l/CC6EOEPOMPCXVLEXGJNHZ52KPG:/var/lib/docker/overlay2/l/AMIGATU6GGLA37IJ3AR4XYCTNN:/var/lib/docker/overlay2/l/2GAWTC7FON7I7IHQBOS6N6IJBT:/var/lib/docker/overlay2/l/R6T5ODPCJAGSQ3MGDKIE4SGDP7,upperdir=/var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/diff,workdir=/var/lib/docker/overlay2/5d5739b6dc3872dbe63b56d35c5d09df443d6a2177f254d91c5fb495c0782233/work,index=off) ``` 3. (hackish) Or is it possible to let users provide a custom path for `mountinfo`? That way, users can custom trim it.

gitea-mirror referenced this issue

2026-05-05 10:25:09 -06:00

[PR #3278] [MERGED] new condition: HAS_NOSOUND #4707

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3278

No description provided.

Rows
Columns