mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3431] Version 0.9.62 forces Dropbox to load in firejail #2157
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2157
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bertradio on GitHub (May 23, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3431
I just upgraded from 0.9.59 to 0.9.62 and now whenever I try and start Dropbox it tries to start in firejail and fails. The command dropbox start on the command line does not load Dropbox but acts as if I had typed firejail dropbox. This does not happen in 0.9.59.
@ghost commented on GitHub (May 23, 2020):
It sounds as if you're using
firecfg, which uses a symlinked /usr/local/bin/dropbox to provide desktop integration. If you don't want that, just remove the symlink. Or you can call Dropbox by its full path viafirejail /usr/bin/dropbox <arguments>. Can you provide output of that command here so we can determine what might be the problem? What OS is this?@bertradio commented on GitHub (May 23, 2020):
Thanks for the speedy reply.
I am running Linux Mint 19.3 64-bit.
I had reverted ot 0.9.59 but for testing did the following:
With this setup both firejail and Dropbox work as expected, but look at the results of the following commands:
So there must be something on my system which tries to load Dropbox in firejail if I just type dropbox (rather than the full path). I do have a file /usr/bin/env but I have no idea what it is (see attached)
Any idea what might be going on?
Thanks
Bert
On Fri, May 22, 2020, at 18:15, glitsj16 wrote:
@rusty-snake commented on GitHub (May 23, 2020):
@bertradio looks like github filters attachments. I can see your screenshots/log-files/… .
finds
grep -l dropbox ~/.local/share/applicationsany files?what shows
which dropbox?Where?
@bertradio commented on GitHub (May 23, 2020):
/home/bert/.local/share/applications has no files named dropbox
On Sat, May 23, 2020, at 07:40, rusty-snake wrote:
@rusty-snake commented on GitHub (May 23, 2020):
sorry, wrong command. I mean
grep -l dropbox ~/.local/share/applications/*.@bertradio commented on GitHub (May 23, 2020):
Changed the startup path in Startup Applications (accessible from the Mint menu)
On Sat, May 23, 2020, at 07:44, Bert Kleinman wrote:
@bertradio commented on GitHub (May 23, 2020):
Found the problem. There was a file named dropbox in /usr/local/bin which was running when I typed dropbox rather than the one in /usr/bin. That was the file which was causing dropbox to try to run in firejail. When I renamed this file, the problem went away. Not sure how this file got into /usr/local/bin but the date on the file was last December. Also don't understand why I did not have this problem with 0.9.59.
In any event, now all is working as it should with 0.9.62.
Thanks
Bert
On Sat, May 23, 2020, at 08:04, Bert Kleinman wrote:
@bertradio commented on GitHub (May 25, 2020):
Looking further in my logs I see that I did at one time run firecfg and that's what probably put the link in /usr/local/bin along with links to a lot of other programs.
So it appears the fault was mine, not firejail's.
On Sat, May 23, 2020, at 12:06, Bert Kleinman wrote:
@rusty-snake commented on GitHub (Jul 16, 2020):
still an issue?
@bertradio commented on GitHub (Jul 16, 2020):
No. The problem was that at some time I had run firecfg which created a bunch of links.
On Thu, Jul 16, 2020, at 00:45, rusty-snake wrote: