SELinux is preventing bwrap from mounton access on the directory /tmp

Ask Fedora
, ,
1

Hi, I noticed that Thunar stopped generating thumbnails out of no where in the last couple of days, I have both tumbler and ffmpegthumbnailer installed, made sure the tumblerd.service is loaded and running, so I launched Tumbler in debugging support and then opened Thunar to see the output and this was it

tumblerd-DEBUG: 15:18:50.188: Starting job 1
tumbler-pixbuf-thumbnailer-DEBUG: 15:18:50.190: Handling URI 'file:///home/ash/Ax-Shell.png'
2025-12-01T13:18:50.192289Z DEBUG glycin::gobject: Initialized logging
2025-12-01T13:18:50.194004Z DEBUG glycin::sandbox: Testing bwrap availability with: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--seccomp" "14" "/usr/bin/true"
2025-12-01T13:18:50.200598Z DEBUG glycin::sandbox: bwrap availability test returned: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "Setting process memory limit\nbwrap: Failed to mount tmpfs: Permission denied\n" } (Signal: None, Code: Some(1))
2025-12-01T13:18:50.200672Z DEBUG glycin::sandbox: bwrap sandboxing available: true
2025-12-01T13:18:50.200686Z DEBUG glycin::pool: No existing loader/editor in pool. Spawning new one.
2025-12-01T13:18:50.202812Z DEBUG glycin::dbus: Spawning loader/editor:
    "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--seccomp" "15" "/usr/libexec/glycin-loaders/2+/glycin-image-rs" "--dbus-fd" "14"
2025-12-01T13:18:50.207513Z DEBUG glycin::dbus: Loader stderr: Setting process memory limit
2025-12-01T13:18:50.210654Z DEBUG glycin::dbus: Loader stderr: bwrap: Failed to mount tmpfs: Permission denied
2025-12-01T13:18:50.211096Z DEBUG glycin::dbus: stderr disconnected without error
2025-12-01T13:18:50.211120Z DEBUG glycin::dbus: stdout disconnected without error
2025-12-01T13:18:50.211154Z DEBUG glycin::dbus: Process exited: Some(Some(1)) Ok(ExitStatus(unix_wait_status(256)))
tumblerd-DEBUG: 15:18:50.219: Error signal for job 1: Code 8, message: (domain gdk-pixbuf-error-quark, code 0) Loader process exited early with status '1'Command:
 "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--seccomp" "15" "/usr/libexec/glycin-loaders/2+/glycin-image-rs" "--dbus-fd" "14"
tumblerd-DEBUG: 15:18:50.220: URIs:
  file:///home/ash/Ax-Shell.png

and with the help of LLM, it suggested that the problem might be in SELinux and this was the output of the journal

$journalctl -t setroubleshoot
Dec 01 15:18:54 fedora setroubleshoot[6007]: SELinux is preventing bwrap from mounton access on the directory /tmp. For complete SELinux messages run: sealert -l 304f8ea3-6225-4439-b8a9-4097e198dc6a
Dec 01 15:18:54 fedora setroubleshoot[6007]: SELinux is preventing bwrap from mounton access on the directory /tmp.
                                             
                                             *****  Plugin catchall (100. confidence) suggests   **************************
                                             
                                             If you believe that bwrap should be allowed mounton access on the tmp directory by default.
                                             Then you should report this as a bug.
                                             You can generate a local policy module to allow this access.
                                             Do
                                             allow this access for now by executing:
                                             # ausearch -c 'bwrap' --raw | audit2allow -M my-bwrap
                                             # semodule -X 300 -i my-bwrap.pp

and

$sealert -l 304f8ea3-6225-4439-b8a9-4097e198dc6a 
SELinux is preventing bwrap from mounton access on the directory /tmp.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that bwrap should be allowed mounton access on the tmp directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'bwrap' --raw | audit2allow -M my-bwrap
# semodule -X 300 -i my-bwrap.pp


Additional Information:
Source Context                unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
Target Context                system_u:object_r:tmp_t:s0
Target Objects                /tmp [ dir ]
Source                        bwrap
Source Path                   bwrap
Port                          <Unknown>
Host                          fedora
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-42.17-1.fc43.noarch
Local Policy RPM              selinux-policy-targeted-42.17-1.fc43.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     fedora
Platform                      Linux fedora 6.17.8-300.fc43.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Nov 14 01:47:12 UTC 2025
                              x86_64
Alert Count                   209
First Seen                    2025-11-30 14:31:13 EET
Last Seen                     2025-12-01 15:35:27 EET
Local ID                      304f8ea3-6225-4439-b8a9-4097e198dc6a

Raw Audit Messages
type=AVC msg=audit(1764596127.941:555): avc:  denied  { mounton } for  pid=9007 comm="bwrap" path="/tmp" dev="tmpfs" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0


Hash: bwrap,thumb_t,tmp_t,dir,mounton

Where should I report this bug?

N.B: I had a warning after updating SELinux as mentioned here, if that is related

2 Likes
2

I see you found my Bugzilla report. Also take a look at my PDF thread. Seems that bwrap is super buggy. When I first upgraded to 43 it was causing my volumeicon not to show up in the panel. My son had to fix that by writing a patch. Small steps… The thumbnail thing is annoying. Also after the upgrade I also had to install glycin-tumbnailer to get screenshot thumbnails to show up on the desktop.

I didn’t see if you opened up a new bug report over there on Bugzilla. Would probably be a good idea.

BTW, I am using the MATE-Compiz spin and it appears that you are using Xfce.

3

If you look at the PDF thread you will see that I am using ps-ax from a terminal to look at what bwrap is doing. That changed from when I just booted up to after I downloaded a PDF file. In my case SELinux is not denying anything, it is simply notifying. So the PDF download still works.

I do wonder if there was an SELinux update that just came through that might have changed things since you said this was happening in the last few days. I don’t know if you could roll that back. But setting SELinux to permissive may help in the testing. And then you can always set it back to enforcing. There were a couple of good videos that I watched on YouTube relating to SELinux and how to deal with issues. Some of it is a bit over my head but it was also some good information.

4

I just set SELinux’s mode to permissive and the thumbnails generated immediately, when I set it back to enforcing new thumbnails stopped generating

5

I will open a bug report

1 Like
6

The suggested fix was provided by the messages you qouted:

You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'bwrap' --raw | audit2allow -M my-bwrap
# semodule -X 300 -i my-bwrap.pp

So run the ausearch and semodule command as shown.

You can report the issue to Bugzilla using the sealert command.

7

There is definitely a bug with bwrap and SELinux interacting. I got the same SEAlert message about bwrap, mounton and the tmp directory by simply copying and pasting a PDF file. I do wish that it would get fixed.

A workaround would be to build that module. But that doesn’t get us to the reason for it happening in the first place. If you do file that bug report over at Bugzilla then maybe put in SELinux for the component. I don’t know… I believe I put in bubblewrap. It’s one or the other and how they are interacting.

8

You might try this command to just set thumb_t to permissive. This is where I am right now. And that is the reason my thumbnails are still showing up, even though I am getting those SELinux alerts…

sudo semanage permissive -a thumb_t
9

Why not just turn the alerts off if you aren’t interested in seeing them - you’re running in permissive mode for them anyway so you’re not getting any protection by having the rule enabled but ignored.

I’m not a Gnome (or Mate) user, but I presume you can open the troubleshooter sealert up and turn the alerts off:

image
image785Ă—280 22.5 KB

10

Isn’t it better to just have one element in permissive mode and not the entire system? Also is it not true that using setenforce permissive from the command line only works until the next boot? I understand that if you want to constantly run in permissive mode then you need to edit the config file.

Also, for me I would still want the alerts to show up for other things. I don’t know if OP cares about that or not. In his case, building that module might be the best thing to do (post 6).

11

Indeed - I prefer to have notifications on, and I deal with issues in se as I find them (it’s often snaps to be fair which is why I avoid them whenever possible).

I only mention this as I’ve seen that you’ve noted the fact that you’re constantly hassled when downloading pdf’s with creating thumbnails and so on, and your sons patience is wearing thin :slight_smile:

I actually thought this was your thread where we’re discussing why this happens and how to resolve it without waiting for someone upstream to update the thumb_t context to permit the creation and mounting of temp file systems.

1 Like
12

Yeah. I get it. No, in this thread he was having issues with thumbnails not showing up in Thunar and that was a recent issue for him. As you can see earlier on in the thread, the issue did go away when he set the SELinux to permissive. In my case, I rarely download PDF files so it isn’t much of an issue. His issue is a bit worse than mine frankly but still basically the same issue (bwrap and SELinux). So he basically has two options. Option 1 is to build the module. Option 2 would be to put thumb_t into permissive but that would mean the alerts would still be showing up.

It does seem like maybe there is some progress on this as I only got 4 alerts last time instead of the 11 or so I had gotten before…

Also, I sent him a message in the hope that he will check in again here. He has filed the bug report as well. I saw it when I logged in over at Bugzilla.

Also in my case I will know that the issue has been solved if I download a PDF in the future and the alerts don’t come up. So there is that.

13

FYI, I fixed this here fix: unbreak thumbnailing for Thunar/tumblerd by RoyalOughtness · Pull Request #2981 · fedora-selinux/selinux-policy · GitHub

Once v42.19 is tagged and shipped, it will be resolved.

@ashley-paul-12345 If you want to re-enable selinux enforcing mode in the meantime, installing this CIL (semodule -i unbreakthunarthumbs.cil) will fix the issue, just don’t forget to uninstall it (semodule -r unbreakthunarthumbs) once the real fix ships:

(allow thumb_t tmp_t (dir (mounton)))
(allow thumb_t tmpfs_t (filesystem (mount unmount)))
(allow thumb_t devpts_t (filesystem (mount)))

1 Like
14

I just have a couple of questions about creating these modules… First of all, is selinux-policy-devel needed? I have been reading so much info lately that at times I feel like my head is spinning. Also if that package gets installed is there anything needed in order for it to work. And finally I am guessing that you just need to use an editor to creat the cil file and then you issue the command semodule -i unbreakthunarthumbs.cil.

The reason I am asking is because I think this module may also solve some of the issues that I am having on the MATE desktop where I am getting very similar SELinux alert messages.

15

You can create the rule using these commands

ausearch -c 'bwrap' --raw | audit2allow -M my-bwrap
semodule -X 300 -i my-bwrap.pp

That would create the module in “pp” format rather than “cil” format, but it would do the same thing.

1 Like
16

thanks, i will just wait until the v42.19 is shipped

17

thanks i tried it and it works, just there is a missing ( in the first line before mounton

1 Like
18

The Fedora 43 update:

https://bodhi.fedoraproject.org/updates/FEDORA-2025-3d2ca8e0f4

2 Likes
19

thanks, i updated and it works

1 Like