github-starred/firejail

Fork 0

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

[GH-ISSUE #1013] "Error mkdir" appears inconsistently #690

New issue

Closed

opened 2026-05-05 06:27:03 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:27:03 -06:00

Owner

Originally created by @randyheydon on GitHub (Dec 30, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1013

I regularly start two programs with firejail in my xinitrc. Rarely, but without any pattern I can find, one or both of them will fail, printing this to stderr:

Error mkdir: fs.c:38 create_dir_as_root: File exists

The commands in the xinitrc file were originally firejail syncthing-gtk --minimized & and firejail redshift-gtk -l [location] &. When a failure occurs, rerunning those commands will reliable start the program in a jail. In order to capture this error message, I have changed the commands in the xinitrc to:

sh -c "firejail --debug syncthing-gtk --minimized > ~/sync_stdout 2>~/sync_stderr" &
sh -c "firejail --debug redshift-gtk -l [location] > ~/red_stdout 2>~/red_stderr" &

When this error is hit, nothing else appears on stdout or stderr. Both of these commands are using custom profiles, but it doesn't look like firejail is even getting far enough to read them.

Originally created by @randyheydon on GitHub (Dec 30, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/1013 I regularly start two programs with firejail in my xinitrc. Rarely, but without any pattern I can find, one or both of them will fail, printing this to stderr: ``` Error mkdir: fs.c:38 create_dir_as_root: File exists ``` The commands in the xinitrc file were originally `firejail syncthing-gtk --minimized &` and `firejail redshift-gtk -l [location] &`. When a failure occurs, rerunning those commands will reliable start the program in a jail. In order to capture this error message, I have changed the commands in the xinitrc to: ``` sh -c "firejail --debug syncthing-gtk --minimized > ~/sync_stdout 2>~/sync_stderr" & sh -c "firejail --debug redshift-gtk -l [location] > ~/red_stdout 2>~/red_stderr" & ``` When this error is hit, nothing else appears on stdout or stderr. Both of these commands are using custom profiles, but it doesn't look like firejail is even getting far enough to read them.

gitea-mirror

2026-05-05 06:27:03 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 06:27:07 -06:00

Author

Owner

@thomasjfox commented on GitHub (Jan 9, 2017):

Could you add a "sleep 3" between the two background forked commands?
May be it's a timing issue if two firejail instances are starting up at the same time.

@thomasjfox commented on GitHub (Jan 9, 2017): Could you add a "sleep 3" between the two background forked commands? May be it's a timing issue if two firejail instances are starting up at the same time.

gitea-mirror commented

2026-05-05 06:27:09 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 9, 2017):

I think this is it, thanks @thomasjfox! Both instances are competing to create directories in /run, stepping on each other. When you start the computer /run is not populated. The first firejail instance will create a bunch of directories there:

$ find /run/firejail
/run/firejail/mnt
/run/firejail/firejail.lock
/run/firejail/firejail.ro.file
/run/firejail/firejail.ro.dir
/run/firejail/appimage
/run/firejail/x11
/run/firejail/name
/run/firejail/bandwidth
/run/firejail/network

Two firejail instances trying to create the same bunch will clash, one of them will fail miserably. I'll put a file lock or something under /tmp to fix it. Until then, add a sleep(3).

@netblue30 commented on GitHub (Jan 9, 2017): I think this is it, thanks @thomasjfox! Both instances are competing to create directories in /run, stepping on each other. When you start the computer /run is not populated. The first firejail instance will create a bunch of directories there: ````` $ find /run/firejail /run/firejail/mnt /run/firejail/firejail.lock /run/firejail/firejail.ro.file /run/firejail/firejail.ro.dir /run/firejail/appimage /run/firejail/x11 /run/firejail/name /run/firejail/bandwidth /run/firejail/network ````` Two firejail instances trying to create the same bunch will clash, one of them will fail miserably. I'll put a file lock or something under /tmp to fix it. Until then, add a sleep(3).

gitea-mirror commented

2026-05-05 06:27:13 -06:00

Author

Owner

@BafDyce commented on GitHub (Jun 29, 2017):

Is this issue still relevant?

Since the issue was reported (v0.9.44.2), the code for creating directories (recursively) changed quite a lot.
I also experimented a bit (with the latest version) with launching multiple firejail processes at the same time, did not have a single crash.

@BafDyce commented on GitHub (Jun 29, 2017): Is this issue still relevant? Since the issue was reported (v0.9.44.2), the code for creating directories (recursively) changed quite a lot. I also experimented a bit (with the latest version) with launching multiple firejail processes at the same time, did not have a single crash.

gitea-mirror commented

2026-05-05 06:27:16 -06:00

Author

Owner

@randyheydon commented on GitHub (Jun 29, 2017):

As of yesterday, I was still getting failures to launch with version 0.9.48. I did not check the error text, so I suppose it could have been something else, but I don't know for certain. Note that this only applies on firejail's first run after startup; after it's been run, any number of other firejail instances can be started simultaneously without issue.

@randyheydon commented on GitHub (Jun 29, 2017): As of yesterday, I was still getting failures to launch with version 0.9.48. I did not check the error text, so I suppose it could have been something else, but I don't know for certain. Note that this only applies on firejail's first run after startup; after it's been run, any number of other firejail instances can be started simultaneously without issue.

gitea-mirror commented

2026-05-05 06:27:18 -06:00

Author

Owner

@BafDyce commented on GitHub (Jun 30, 2017):

Yeah, I know that it only happens on initial startup. Thats why I deleted all contents from `/run/firejail' before launching firejail again. However, it seems like the problem is still there.

Can you check if my patch (#1359) fixes your problem?

@BafDyce commented on GitHub (Jun 30, 2017): Yeah, I know that it only happens on initial startup. Thats why I deleted all contents from `/run/firejail' before launching firejail again. However, it seems like the problem is still there. Can you check if my patch (#1359) fixes your problem?

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#690

No description provided.

Rows
Columns