[GH-ISSUE #975] Steam doesn't start on Ubuntu 16.04

gitea-mirror commented

2026-05-05 06:24:03 -06:00

Owner

Originally created by @ghost on GitHub (Dec 13, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/975

I had to leave Arch because of the instability of mesa-git, so I'm on Ubuntu 16.04 for the moment.

On Arch, Steam launches fine with the latest Firejail, but on Ubuntu 16.04 it doesn't. (firejail version 0.9.44.2-1)

I don't have time to find out exactly why this happens, but I edited the Steam profile and commented one line at a time, but it didn't help.

Here's the terminal output, I hope someone could explain what to do.

Error: Couldn't find bootstrap, it's not safe to reset Steam. Please contact technical support.

Parent is shutting down, bye...

Originally created by @ghost on GitHub (Dec 13, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/975 I had to leave Arch because of the instability of mesa-git, so I'm on Ubuntu 16.04 for the moment. On Arch, Steam launches fine with the latest Firejail, but on Ubuntu 16.04 it doesn't. (firejail version 0.9.44.2-1) I don't have time to find out exactly why this happens, but I edited the Steam profile and commented one line at a time, but it didn't help. Here's the terminal output, I hope someone could explain what to do. > Error: Couldn't find bootstrap, it's not safe to reset Steam. Please contact technical support. > >Parent is shutting down, bye...

gitea-mirror

2026-05-05 06:24:03 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 06:24:13 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

I'll give it a try, thanks.

@netblue30 commented on GitHub (Dec 13, 2016): I'll give it a try, thanks.

gitea-mirror commented

2026-05-05 06:24:15 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

~~Updated 16.04 today. I'm getting a slightly different error, something about nvidia drivers - I don't have nvidia installed!~~

~~Open /etc/firejail/snap.profile in a text editor (sudo gedit /etc/firejail/snap.profile) and comment out caps.keep line (add a # in front of it). It fixes it for me, give it a try on your system~~

@netblue30 commented on GitHub (Dec 13, 2016): ~~Updated 16.04 today. I'm getting a slightly different error, something about nvidia drivers - I don't have nvidia installed!~~ ~~Open /etc/firejail/snap.profile in a text editor (sudo gedit /etc/firejail/snap.profile) and comment out caps.keep line (add a # in front of it). It fixes it for me, give it a try on your system~~

gitea-mirror commented

2026-05-05 06:24:17 -06:00

Author

Owner

@skinkade commented on GitHub (Dec 13, 2016):

Tangential note for others: a Steam update yesterday rendered it broken for me with firejail 0.9.42 on Ubuntu 14.04. Thankfully updating to 0.9.44.2 resolved the issue.

@skinkade commented on GitHub (Dec 13, 2016): Tangential note for others: a Steam update yesterday rendered it broken for me with firejail 0.9.42 on Ubuntu 14.04. Thankfully updating to 0.9.44.2 resolved the issue.

gitea-mirror commented

2026-05-05 06:24:19 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 14, 2016):

Sorry, I have to take back the previous message, I was confusing steam with snap... and I run in a different snap problem!

@netblue30 commented on GitHub (Dec 14, 2016): Sorry, I have to take back the previous message, I was confusing steam with snap... and I run in a different snap problem!

gitea-mirror commented

2026-05-05 06:24:21 -06:00

Author

Owner

@ghost commented on GitHub (Dec 16, 2016):

@netblue30 After returning to the FOSS drivers Steam started, so to me this problem only happens if I use the AMDGPU-PRO stack, which just recently added support for Southern Islands cards (that's why I was testing it).

I leave it to you to decide whether to close this issue or not, because I'm confident there are many gamers using the -PRO stack with firejail.

@ghost commented on GitHub (Dec 16, 2016): @netblue30 After returning to the FOSS drivers Steam started, so to me this problem only happens if I use the AMDGPU-PRO stack, which just recently added support for Southern Islands cards (that's why I was testing it). I leave it to you to decide whether to close this issue or not, because I'm confident there are many gamers using the -PRO stack with firejail.

gitea-mirror commented

2026-05-05 06:24:23 -06:00

Author

Owner

@ghost commented on GitHub (Dec 17, 2016):

@amarildojr I had Steam issues when I upgraded firejail recently, maybe you have the same ones? I run Steam in its own home directory using the --private=directory option, and the new profiles disable too many things. For example, running this command:

firejail --private=/space/steam --noblacklist=/home/pete/\* --debug-blacklists

..still lists the following as blacklisted:

Disable /home/pete/.local/share/Steam
Disable /home/pete/.local/share/aspyr-media
Disable /home/pete/.local/share/vulkan
Disable /home/pete/.pki/nssdb

It seems these can't be un-blacklisted, so the workaround is to run with --no-profile but this is less secure. Maybe this is your issue?

@netblue30 If a default profile has a blacklist for something in ${HOME} when --private=dir is in effect, firejail blacklists things in the private directory. In my setup this is unnecessary as I have a separate directory for each program I run. What's your opinion on this? Should we make it so that contents of private directories can never be blacklisted? Or maybe an option like --noblacklist-private which disables blacklisting in private directories?

After all, the default profile files list all sorts of useful things and it would be great to still get them blacklisted while saying "everything in ${HOME} is fine as it's a private directory".

@ghost commented on GitHub (Dec 17, 2016): @amarildojr I had Steam issues when I upgraded firejail recently, maybe you have the same ones? I run Steam in its own home directory using the `--private=directory` option, and the new profiles disable too many things. For example, running this command: `firejail --private=/space/steam --noblacklist=/home/pete/\* --debug-blacklists` ..still lists the following as blacklisted: `Disable /home/pete/.local/share/Steam` `Disable /home/pete/.local/share/aspyr-media` `Disable /home/pete/.local/share/vulkan` `Disable /home/pete/.pki/nssdb` It seems these can't be un-blacklisted, so the workaround is to run with `--no-profile` but this is less secure. Maybe this is your issue? @netblue30 If a default profile has a blacklist for something in `${HOME}` when `--private=dir` is in effect, firejail blacklists things in the private directory. In my setup this is unnecessary as I have a separate directory for each program I run. What's your opinion on this? Should we make it so that contents of private directories can never be blacklisted? Or maybe an option like `--noblacklist-private` which disables blacklisting in private directories? After all, the default profile files list all sorts of useful things and it would be great to still get them blacklisted while saying "everything in ${HOME} is fine as it's a private directory".

gitea-mirror commented

2026-05-05 06:24:24 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 17, 2016):

@pmillerchip

If a default profile has a blacklist for something in ${HOME} when --private=dir is in effect, firejail blacklists things in the private directory.

This is true, the filesystem operations are ordered as follows: mount namespace, chroot/overlayfs/private, whitelists, blacklists.

I can add a config entry in /etc/firejail/firejail.confg file to disable blacklists and whitelists if a private command related to home directory is already present. This way you don't need to modify your existing profiles, just the entry in /etc/firejail/firejail.config. What do you think? We can even enable it by default, blacklisting on a private home directory doesn't make sense in most cases - and probably is the same for chroot.

@netblue30 commented on GitHub (Dec 17, 2016): @pmillerchip > If a default profile has a blacklist for something in ${HOME} when --private=dir is in effect, firejail blacklists things in the private directory. This is true, the filesystem operations are ordered as follows: mount namespace, chroot/overlayfs/private, whitelists, blacklists. I can add a config entry in /etc/firejail/firejail.confg file to disable blacklists and whitelists if a private command related to home directory is already present. This way you don't need to modify your existing profiles, just the entry in /etc/firejail/firejail.config. What do you think? We can even enable it by default, blacklisting on a private home directory doesn't make sense in most cases - and probably is the same for chroot.

gitea-mirror commented

2026-05-05 06:24:26 -06:00

Author

Owner

@ghost commented on GitHub (Dec 17, 2016):

@netblue30 That sounds like a good idea, an option like --enable-private-blacklist or something. There might be some edge cases where people want to blacklist things in a private directory, maybe if someone uses a shared private directory for two applications? Having it default to not blacklisting in private directories makes sense and would make life easier for me!

@ghost commented on GitHub (Dec 17, 2016): @netblue30 That sounds like a good idea, an option like `--enable-private-blacklist` or something. There might be some edge cases where people want to blacklist things in a private directory, maybe if someone uses a shared private directory for two applications? Having it default to not blacklisting in private directories makes sense and would make life easier for me!

gitea-mirror referenced this issue

2026-05-05 10:06:27 -06:00

[PR #665] [MERGED] Add profiles for tar (gtar), unzip and unrar #3707

Rows
Columns

[GH-ISSUE #975] Steam doesn't start on Ubuntu 16.04 #665