[GH-ISSUE #5205] firejail starting with systemd and different user well, but inside shell not.

gitea-mirror commented

2026-05-05 09:34:41 -06:00

Owner

Originally created by @osevan on GitHub (Jun 16, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5205

I found since months a bug in firejail.

Im starting firejail with systemd and everything is working.

But when I try to start

sudo -u nginx -H firejail --debug /usr/sbin/nginx &

Firejail complains my server.local and globals.local file

Error: cannot access profile file : server.local

But with same profile and user settings with systemd firejail running well.

Thanks and

Best regards

Originally created by @osevan on GitHub (Jun 16, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5205 I found since months a bug in firejail. Im starting firejail with systemd and everything is working. But when I try to start sudo -u nginx -H firejail --debug /usr/sbin/nginx & Firejail complains my server.local and globals.local file Error: cannot access profile file : server.local But with same profile and user settings with systemd firejail running well. Thanks and Best regards ![-5285060938694769451_121](https://user-images.githubusercontent.com/77795961/174102710-89026ece-5dcb-452d-bb77-c046f67a6226.jpg) ![-5285060938694769452_121](https://user-images.githubusercontent.com/77795961/174102724-34a702fc-d827-4b20-85c5-22b9afb1a0cb.jpg)

gitea-mirror commented

2026-05-05 09:34:43 -06:00

Author

Owner

@ghost commented on GitHub (Jun 16, 2022):

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

@ghost commented on GitHub (Jun 16, 2022): Sounds like user `nginx` doesn't have read-access rights to these .local files. Do you have those in `/etc/firejail` or under your regular user's ${HOME} in `~/.config/firejail`? Somewhere else? Also, it would be helpful to know/see if your `systemd unit` uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

gitea-mirror commented

2026-05-05 09:34:44 -06:00

Author

Owner

@osevan commented on GitHub (Jun 16, 2022):

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

You mean moving *.local files to /etc/firejail helps?

Because im creating user without homedirectory and setting shell to /bin/false.

Even when I set shell to /bin/bash or sh this happens

I have shell none in config.

And back to systemd

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing,

I have setupped my own systemd file and I didn't planted security cgroup and cname stuff by systemd - so the answer is clearly no.

@osevan commented on GitHub (Jun 16, 2022): > Sounds like user `nginx` doesn't have read-access rights to these .local files. Do you have those in `/etc/firejail` or under your regular user's ${HOME} in `~/.config/firejail`? Somewhere else? > > Also, it would be helpful to know/see if your `systemd unit` uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug. You mean moving *.local files to /etc/firejail helps? Because im creating user without homedirectory and setting shell to /bin/false. Even when I set shell to /bin/bash or sh this happens I have shell none in config. And back to systemd Also, it would be helpful to know/see if your `systemd unit` uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, I have setupped my own systemd file and I didn't planted security cgroup and cname stuff by systemd - so the answer is clearly no.

gitea-mirror commented

2026-05-05 09:34:45 -06:00

Author

Owner

@osevan commented on GitHub (Jun 16, 2022):

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Firejail installing these files everytime in

/usr/local/etc/firejail

@osevan commented on GitHub (Jun 16, 2022): > Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else? Firejail installing these files everytime in /usr/local/etc/firejail

gitea-mirror commented

2026-05-05 09:34:46 -06:00

Author

Owner

@ghost commented on GitHub (Jun 16, 2022):

You mean moving *.local files to /etc/firejail helps?

I cannot be certain this would help, because I don't know the specifics on how you've created/limited the nginx user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail.

So yes, give that a try. You should see straight-away if that fixes this or not.

Firejail installing these files everytime in
/usr/local/etc/firejail

Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a 0.9.70 release that has a fix for CVE-2022-31214. Time to upgrade your Firejail!

@ghost commented on GitHub (Jun 16, 2022): > You mean moving *.local files to /etc/firejail helps? I cannot be certain this would help, because I don't know the specifics on how you've created/limited the `nginx` user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail. So yes, give that a try. You should see straight-away if that fixes this or not. > Firejail installing these files everytime in /usr/local/etc/firejail Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a [0.9.70](https://github.com/netblue30/firejail/releases/tag/0.9.70) release that has a fix for CVE-2022-31214. Time to upgrade your Firejail!

gitea-mirror commented

2026-05-05 09:34:47 -06:00

Author

Owner

@osevan commented on GitHub (Jun 16, 2022):

You mean moving *.local files to /etc/firejail helps?

I cannot be certain this would help, because I don't know the specifics on how you've created/limited the nginx user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail.

So yes, give that a try. You should see straight-away if that fixes this or not.

Firejail installing these files everytime in
/usr/local/etc/firejail

Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a 0.9.70 release that has a fix for CVE-2022-31214. Time to upgrade your Firejail!

Im arch user and my vm running debian bullseye.

Im always compile manualy software

You think upgrading will help me?

@osevan commented on GitHub (Jun 16, 2022): > > You mean moving *.local files to /etc/firejail helps? > > I cannot be certain this would help, because I don't know the specifics on how you've created/limited the `nginx` user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail. > > So yes, give that a try. You should see straight-away if that fixes this or not. > > > Firejail installing these files everytime in > > /usr/local/etc/firejail > > Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a [0.9.70](https://github.com/netblue30/firejail/releases/tag/0.9.70) release that has a fix for [CVE-2022-31214](https://github.com/advisories/GHSA-m2xv-wgqg-4gxh). Time to upgrade your Firejail! Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me?

gitea-mirror commented

2026-05-05 09:34:49 -06:00

Author

Owner

@ghost commented on GitHub (Jun 16, 2022):

Im arch user and my vm running debian bullseye.
Im always compile manualy software
You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

@ghost commented on GitHub (Jun 16, 2022): > Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me? Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the `--prefix=/usr` option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

gitea-mirror commented

2026-05-05 09:34:49 -06:00

Author

Owner

@osevan commented on GitHub (Jun 16, 2022):

Im arch user and my vm running debian bullseye.
Im always compile manualy software
You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem?

And --prefix=/usr flag installing profiles automaticaly to /etc/firejail correctly and binary files in /usr/bin/ ?

@osevan commented on GitHub (Jun 16, 2022): > > Im arch user and my vm running debian bullseye. > > Im always compile manualy software > > You think upgrading will help me? > > Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the `--prefix=/usr` option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'. You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem? And --prefix=/usr flag installing profiles automaticaly to /etc/firejail correctly and binary files in /usr/bin/ ?

gitea-mirror commented

2026-05-05 09:34:50 -06:00

Author

Owner

@kmk3 commented on GitHub (Jun 16, 2022):

@osevan commented on Jun 16:

Im arch user and my vm running debian bullseye. Im always compile
manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those
local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to
see if that fixes things. Technically the upgrade won't help you there IMO.
But running a Firejail version that's known to be vulnerable for a specific
CVE isn't the safest thing to do. Whenever you decide to do such a manual
build of 0.9.70, you might want to consider adding the --prefix=/usr
option to the configure command. Again, it's not strictly needed, but it
will get your 'regular' and 'VM' versions on par, what simplifies things
whenever you're faced with something like this current issue. Call it
'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem?

And --prefix=/usr flag installing profiles automaticaly to /etc/firejail
correctly and binary files in /usr/bin/ ?

Regardless of whether it solves this problem, reducing system deviations helps
with debugging.

On Debian you can easily build a firejail .deb package from source and install
it:

# Note: Running ./configure before `make deb` will probably not be needed in
# the next release
# Edit: Ignore the above comment; mkdeb.sh still depends on config.mk (see
# #5219)
./configure
make deb
dpkg -i firejail*.deb

This is basically how the official Debian package is built (and make deb uses
--prefix=/usr internally), so your setup will likely be more similar to the
ones of other Debian users.

In general, it's better to install things through the system package manager,
as it tracks which files belong to the package and so it can better ensure a
cleaner upgrade/removal and it can warn you when there are conflicts with the
configuration files in /etc.

@kmk3 commented on GitHub (Jun 16, 2022): @osevan commented [on Jun 16](https://github.com/netblue30/firejail/issues/5205#issuecomment-1158240326): > > > Im arch user and my vm running debian bullseye. Im always compile > > > manualy software You think upgrading will help me? > > > > > > Thanks, that explains things. I still think you need to try moving those > > local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to > > see if that fixes things. Technically the upgrade won't help you there IMO. > > But running a Firejail version that's known to be vulnerable for a specific > > CVE isn't the safest thing to do. Whenever you decide to do such a manual > > build of 0.9.70, you might want to consider adding the `--prefix=/usr` > > option to the configure command. Again, it's not strictly needed, but it > > will get your 'regular' and 'VM' versions on par, what simplifies things > > whenever you're faced with something like this current issue. Call it > > 'recommended'. > > You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem? > > And --prefix=/usr flag installing profiles automaticaly to /etc/firejail > correctly and binary files in /usr/bin/ ? Regardless of whether it solves this problem, reducing system deviations helps with debugging. On Debian you can easily build a firejail .deb package from source and install it: ```sh # Note: Running ./configure before `make deb` will probably not be needed in # the next release # Edit: Ignore the above comment; mkdeb.sh still depends on config.mk (see # #5219) ./configure make deb dpkg -i firejail*.deb ``` This is basically how the official Debian package is built (and `make deb` uses `--prefix=/usr` internally), so your setup will likely be more similar to the ones of other Debian users. In general, it's better to install things through the system package manager, as it tracks which files belong to the package and so it can better ensure a cleaner upgrade/removal and it can warn you when there are conflicts with the configuration files in /etc.

gitea-mirror commented

2026-05-05 09:34:50 -06:00

Author

Owner

@osevan commented on GitHub (Jun 17, 2022):

@osevan commented on Jun 16:

Im arch user and my vm running debian bullseye. Im always compile
manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those
local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to
see if that fixes things. Technically the upgrade won't help you there IMO.
But running a Firejail version that's known to be vulnerable for a specific
CVE isn't the safest thing to do. Whenever you decide to do such a manual
build of 0.9.70, you might want to consider adding the --prefix=/usr
option to the configure command. Again, it's not strictly needed, but it
will get your 'regular' and 'VM' versions on par, what simplifies things
whenever you're faced with something like this current issue. Call it
'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem?
And --prefix=/usr flag installing profiles automaticaly to /etc/firejail
correctly and binary files in /usr/bin/ ?

Regardless of whether it solves this problem, reducing system deviations helps with debugging.

On Debian you can easily build a firejail .deb package from source and install it:
# Note: Running ./configure before `make deb` will probably not be needed in
# the next release
./configure
make deb
dpkg -i firejail*.deb
This is basically how the official Debian package is built (and make deb uses --prefix=/usr internally), so your setup will likely be more similar to the ones of other Debian users.

In general, it's better to install things through the system package manager, as it tracks which files belong to the package and so it can better ensure a cleaner upgrade/removal and it can warn you when there are conflicts with the configuration files in /etc.

Now I did pull to latest git and did not compile with adviced prefix flag and my problem is gone

Latest update fixes my problem.

In my older Firejail version I tested moving files to etc firejail and even than I had same error.

Now reverted etc firejail and latest update solve my problem.

@osevan commented on GitHub (Jun 17, 2022): > @osevan commented [on Jun 16](https://github.com/netblue30/firejail/issues/5205#issuecomment-1158240326): > > > > > Im arch user and my vm running debian bullseye. Im always compile > > > > manualy software You think upgrading will help me? > > > > > > > > > Thanks, that explains things. I still think you need to try moving those > > > local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to > > > see if that fixes things. Technically the upgrade won't help you there IMO. > > > But running a Firejail version that's known to be vulnerable for a specific > > > CVE isn't the safest thing to do. Whenever you decide to do such a manual > > > build of 0.9.70, you might want to consider adding the `--prefix=/usr` > > > option to the configure command. Again, it's not strictly needed, but it > > > will get your 'regular' and 'VM' versions on par, what simplifies things > > > whenever you're faced with something like this current issue. Call it > > > 'recommended'. > > > > > > You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem? > > And --prefix=/usr flag installing profiles automaticaly to /etc/firejail > > correctly and binary files in /usr/bin/ ? > > Regardless of whether it solves this problem, reducing system deviations helps with debugging. > > On Debian you can easily build a firejail .deb package from source and install it: > > ```shell > # Note: Running ./configure before `make deb` will probably not be needed in > # the next release > ./configure > make deb > dpkg -i firejail*.deb > ``` > > This is basically how the official Debian package is built (and `make deb` uses `--prefix=/usr` internally), so your setup will likely be more similar to the ones of other Debian users. > > In general, it's better to install things through the system package manager, as it tracks which files belong to the package and so it can better ensure a cleaner upgrade/removal and it can warn you when there are conflicts with the configuration files in /etc. Now I did pull to latest git and did not compile with adviced prefix flag and my problem is gone Latest update fixes my problem. In my older Firejail version I tested moving files to etc firejail and even than I had same error. Now reverted etc firejail and latest update solve my problem.

gitea-mirror commented

2026-05-05 09:34:51 -06:00

Author

Owner

@osevan commented on GitHub (Jun 24, 2022):

I have same issue again with newest Firejail.

I dunno why )-:

@osevan commented on GitHub (Jun 24, 2022): I have same issue again with newest Firejail. I dunno why )-:

gitea-mirror commented

2026-05-05 09:34:52 -06:00

Author

Owner

@osevan commented on GitHub (Jun 29, 2022):

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

I haven't any locale files in these directorys.

Snd for security im creating users without home directory

I have my problem back :-(

@osevan commented on GitHub (Jun 29, 2022): > Sounds like user `nginx` doesn't have read-access rights to these .local files. Do you have those in `/etc/firejail` or under your regular user's ${HOME} in `~/.config/firejail`? Somewhere else? > > Also, it would be helpful to know/see if your `systemd unit` uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug. I haven't any locale files in these directorys. Snd for security im creating users without home directory I have my problem back :-(

gitea-mirror commented

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

Author

Owner

@osevan commented on GitHub (Jun 12, 2023):

i have tested this bug now on 3 vps, sometimes nothing happens 6 months, but than , when firejail process running too long or restarted things often enough well and successfully, trouble above comes back...

i dont know how to fix it, because, --noprofile works well, but, when i create nginx.profile with only one line trash line like #log nothing starts and i see emerge fcopy files error again... :-(

i know its bad, when i running firejail --debug mode and no usefull information i can post here :-(

even right read access i did try chown -R nginx:nginx /etc/nginx/ and with chown -R root:root /etc/nginx.

but dont forget my nginx profile running well 5-6 months with root:root /etc/nginx and nothing happens.. i dont know what triggers that kind of problem :-(

@osevan commented on GitHub (Jun 12, 2023): i have tested this bug now on 3 vps, sometimes nothing happens 6 months, but than , when firejail process running too long or restarted things often enough well and successfully, trouble above comes back... i dont know how to fix it, because, --noprofile works well, but, when i create nginx.profile with only one line trash line like #log nothing starts and i see emerge fcopy files error again... :-( i know its bad, when i running firejail --debug mode and no usefull information i can post here :-( even right read access i did try chown -R nginx:nginx /etc/nginx/ and with chown -R root:root /etc/nginx. but dont forget my nginx profile running well 5-6 months with root:root /etc/nginx and nothing happens.. i dont know what triggers that kind of problem :-(

gitea-mirror commented

2026-05-05 09:34:54 -06:00

Author

Owner

@osevan commented on GitHub (Jun 12, 2023):

This is strangest firejail bug i got in last 5 years :-(

@osevan commented on GitHub (Jun 12, 2023): This is strangest firejail bug i got in last 5 years :-(

gitea-mirror commented

2026-05-05 09:34:54 -06:00

Author

Owner

@osevan commented on GitHub (Jun 12, 2023):

bug dissappears again suddenly without doing anything :-)

@osevan commented on GitHub (Jun 12, 2023): bug dissappears again suddenly without doing anything :-)

gitea-mirror commented

2026-05-05 09:34:55 -06:00

Author

Owner

@osevan commented on GitHub (Apr 4, 2024):

Hello devs.

We are now in 2024 and on vps debian sid my trouble still exist.

Im installed over make deb everything inside /usr.

And when my profile have shell none, i cant start daemons with systemd

Only when i remove "shell none "

sudo -u mysql -H firejail mydaemon
i receive:

Error : cannot access profile file : server.local

And exit

@osevan commented on GitHub (Apr 4, 2024): Hello devs. We are now in 2024 and on vps debian sid my trouble still exist. Im installed over make deb everything inside /usr. And when my profile have shell none, i cant start daemons with systemd Only when i remove "shell none " sudo -u mysql -H firejail mydaemon i receive: Error : cannot access profile file : server.local And exit

gitea-mirror commented

2026-05-05 09:34:55 -06:00

Author

Owner

@ghost commented on GitHub (Apr 4, 2024):

And when my profile have shell none, i cant start daemons with systemd
...
sudo -u mysql -H firejail mydaemon
Error : cannot access profile file : server.local

The mysql user more than likely doesn't have access rights to ~/.config/firejail/server.local (if that is where you've put it). In general I'd use systemd's sandboxing features instead of firejail (which is by design not very well suited for system daemons). See this wiki page.

That being said, try placing your override in /etc/firejail/server.local and add the allusers option.

@ghost commented on GitHub (Apr 4, 2024): > And when my profile have shell none, i cant start daemons with systemd ... sudo -u mysql -H firejail mydaemon Error : cannot access profile file : server.local The `mysql` user more than likely doesn't have access rights to `~/.config/firejail/server.local` (if that is where you've put it). In general I'd use systemd's sandboxing features instead of firejail (which is by design not very well suited for system daemons). See [this wiki page](https://github.com/netblue30/firejail/wiki/Comparison-of-firejail-and-systemd's-hardening-options). That being said, try placing your override in `/etc/firejail/server.local` and add the `allusers` option.

gitea-mirror commented

2026-05-05 09:34:56 -06:00

Author

Owner

@osevan commented on GitHub (Apr 4, 2024):

Where i can find allusers option?
Ok thx

@osevan commented on GitHub (Apr 4, 2024): Where i can find allusers option? Ok thx