From ArchWiki

What does "depending on your setup" mean?

You are completely correct, I don't know what I was thinking of. I like to test everything, and, at the time of editing, I knew the example worked with '--profile=/etc/firejail/thunar.profile'. Yet, when I tried the example with '--profile=/etc/firejail/Thunar.profile', it failed. Hence the note. Now that you have brought it to my attention, I checked again, and both worked. Go figure! .... The basic example is sound though(?) IrvineHimself (talk) 15:12, 22 October 2017 (UTC)

I've removed the note, should I remove the example? IrvineHimself (talk) 16:35, 22 October 2017 (UTC)
I have removed the Accurate flag. Which example? Could you be more specific? --Fengchao (talk) 23:31, 22 October 2017 (UTC)
The example to launch 'Thunar Bulk Rename' inside a sandbox. IrvineHimself (talk) 00:35, 23 October 2017 (UTC)
If you have time, I think the whole "Desktop files" section should be merged to Configuration. The example could be removed because it is already explained in Configuration. --Fengchao (talk) 05:29, 23 October 2017 (UTC)
I've removed the example. Are you sure that "Configuration" is the best place for the "Desktop files" section? While "Configuration" might benefit from a minor re-write to bring it more in line with the updated page, "Desktop files" seems a more natural fit inside "Using Firejail by default"? IrvineHimself (talk) 14:13, 25 October 2017 (UTC)
Sorry, it should be "Using Firejail by default". I wrongly thought this section belongs to Configuration. --Fengchao (talk) 02:54, 26 October 2017 (UTC)

Questionable statements, e.g. how does "updatedb"....

Again, I can only agree. The entry was there before I tried to update the Firejail page to cover recent developments and rationalize the page layout. When I was trying to figure out why 'Thunar' was not being sandboxed, suggestions like 'updatedb' just produced errors. On the other hand, the specific problem with 'Thunar' is fairly common. See IrvineHimself (talk) 15:15, 22 October 2017 (UTC)

I have tried to clean up the entry to make it more acceptable. Could you let me no if it's okay. IrvineHimself (talk) 14:03, 25 October 2017 (UTC)
Thanks. I have a a question about "Some applications, notably Thunar, run with only one instance. As a result, the profile will not be loaded until the next login". According to the linked report, a new symbolic links needs be created from firejail to /usr/local/bin/Thunar, and then a new login should occur. That seems something different to me or at least some part of the information is left out. -- Alad (talk) 15:19, 25 October 2017 (UTC)
Since it was in the section about troubleshooting symlinks, I didn't think it needed to be explicitly stated. However I edited the entry to reflect your concerns. IrvineHimself (talk) 16:50, 25 October 2017 (UTC)

Some of these workarounds need to be in the sandbox' directories?

If yes? Which? My edit of this being the case for the pulseaudio thing might be incorrect.Jasper1984 (talk) 01:11, 2 December 2017 (UTC)

Apparmor integration

I was studying firejail to sandbox a wine program when I stumbled upon this FAQ question on firejail's github repo wiki about Firejail comparisson with Apparmor. It says "It is recommended to only use AppArmor OR Firejail but not both at the same time for the same app. [...] Many times they will cancel each other out rather than be complementary." which may be a source of attention by users, as it was for me. Should this issue be included in the wiki article? Thanks in advance!

Rahcor (talk) 03:13, 21 November 2020 (UTC) rahcor

Firejail, Firefox and DRM

I'm new here and didn't want to edit the page until I'm more familiar with things. It seems there is a new config option called 'browser-allow-drm' which is set to no by default. If not properly set to yes, the widevine plugin (used by spotify, netflix etc.) crashes when visiting forementioned pages. Should this be mentioned under the topic troubleshooting? Or in firefox's wiki-page?

JoeoJ (talk) 17:32, 22 December 2020 (UTC)

This is already documented in the upstream wiki. I am against duplicating information but a note or a reference is appropriate for this. I would mention this on the Firejail page, not on the Firefox one.
-- NetSysFire (talk) 18:27, 16 March 2021 (UTC)

Steam and Proton

I get why patching profiles after updating firejail is a bad idea, but how can statements like `private-dev` or `private-etc` be ignored? Is `ignore private-dev` in a `.local` file going to work? Anyways as @NetSysFire already mentioned we should not duplicate information that's available elsewhere, but I couldn't find anything on the www so I decided to put it on the wiki. To follow the no-dupe rule, we should remove the seccomp stuff, as it's mentioned in the profile itself.

EDIT: I just tested it: `ignore private-dev` and `ignore private-etc` in a `.local` file do work. I think this whole section can now be removed.

—This unsigned comment is by Mr nUUb (talk) 17:33, 10 April 2021‎ (UTC). Please sign your posts with ~~~~!

Yes, .local files are preferred since they will not get overwritten. The problem with the section is also that it is missing other information. I would have let this stay if there was a bug report about this and information such as which games are impacted. Always report such issues to the Firejail folks. Also check your journal. The blocked syscall will be in a log message by audit. Add it to the seccomp filter and try again. Repeat until you got every syscall.
-- NetSysFire (talk) 17:47, 10 April 2021 (UTC)


I've some suggestions for this wiki page. I will not add them myself because I do a lot work upstream and I believe that downstream documentation should be written by users and not by developers.

  1. Usage: Since firejail 0.9.58 you can use firejail --profile=<profile-name> <program-name> for profiles in /etc/firejail and ~/.config/firejail.
  2. Creating custom profiles >> Profile writing: Since firejail 0.9.62 you can use /usr/share/doc/firejail/profile.template.
  3. Creating custom profiles >> Profile writing >> Persistent local customisation: Since firejail 0.9.58 you can also create .locals in ~/.config/firejail without the need of creating a redirect profile there.
  4. Creating custom profiles >> Testing profiles: --audit was removed in firejail 0.9.66. You can now use sudo jailcheck to check all running sandboxes. (Or my
  5. Since firejail new users can run /usr/lib/firejail/ to do some basic configuration like browser-disable-u2f, browser-allow-drm and firecfg.
  6. If results in xdg-dbus-proxy in optdepends, suggest to install it if it isn't installed.

--Rusty-snake (talk) 12:19, 4 July 2021 (UTC)

These are nice suggestions, thanks! The whole page needs some love IMO but this needs some time to accomplish since it is not a small page.
-- NetSysFire (talk) 16:35, 4 July 2021 (UTC)

One more suggestion: put in a troubles the keyboard with xephyr. This can be solved with this thread. It could be passing parameters with

xephyr-extra-params -keybd ephyr,,,xkbmodel=pc105,xkblayout=es,xkbrules=evdev,xkbvariant=cat

in /etc/firejail/firejail.conf

--Xan (talk) 11:14, 28 May 2023 (UTC)

Warning proposal

As it seems undisputed that the approach is at the very least controversial, there should be no reason not to point that out using the upstream thread that has all the links and arguments in it anyway.

Warning: Firejail uses a controversial approach to sandboxing [1]. Running untrusted code is never safe, sandboxing cannot change this.

-- Hanadoc (talk) 11:46, 9 December 2022 (UTC)

I guess you ignored the part of #Warning where I mentioned these kind of "controversy" statements are redundant and up to user discretion. Either add something concrete, or leave it as is. -- Alad (talk) 13:36, 9 December 2022 (UTC)
How is this redundant when it is nowhere else to be found? Nowhere else on the page can a user find any hint about the risks involved in using this application. The only vague indicator would be the mention of SUID, which in itself does not at all replace the information I proposed to be added. A user who finds firejail through this wiki page does not get any chance to learn about the risks involved. -- Hanadoc (talk) 14:13, 9 December 2022 (UTC)
The warning must be factual and objective. A statement pointing out a controversy is not worth a warning. — Lahwaacz (talk) 14:57, 9 December 2022 (UTC)

New attempt

Warning: Firejail runs as effective root which has lead to privilege escalations in the past [2]. Running untrusted code is never safe, sandboxing cannot change this.

This should both be factual and objective as even the developers have confirmed this. (See CVEs)

I would like to add that I had been running firejail for a few years by now without being aware of this and would like to make sure that anyone finding it in this wiki, get at least the chance to make a conscious decision about accepting these risks.

I am against adding such a warning and would prefer adding a generic SUID blurb to Security which we can link on here. By the way, you can apply the exact same warning to sudo, too, as it is both a SUID binary and had issues with that in the past. Firejail has a positive history of fixing vulnerabilities promptly when they are reported. Almost all SUID-dependant applications had vulnerabilities in the past. Highlighting firejail in particular does not make any sense here, but as I said making the user aware about the risk of SUID in general is something I do support.
-- NetSysFire (talk) 12:33, 11 December 2022 (UTC)
+1 from me on the generic warning in the Security page, it would allow de-duplicating these kind of warning on all the related pages. --Erus Iluvatar (talk) 13:00, 11 December 2022 (UTC)
It's fine to me provided the Security blurb is linked from the Firejail article. The natural place for this seems Firejail#Installation, other aspects like namespaces and whitelists/blacklists are also mentioned there. -- Alad (talk) 18:12, 11 December 2022 (UTC) edit: one option is to create a SUID redirect and link to it from the article. -- Alad (talk) 18:16, 11 December 2022 (UTC)