mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #836] vlc: program does not start with --started-from-file #566
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#566
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 @ghost on GitHub (Oct 5, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/836
Hello,
Today, after many months away from Linux, I decided to give VLC a try here. It all worked fine one month ago.
For some reason, I can't open any file with VLC or start it from KDE's menu, because of the
--started-from-filepart in KDE's launch properties. Output:When removing that part, it starts normally:
Following suggestions in https://github.com/netblue30/firejail/issues/814 didn't help. I just compiled firejail-git in Arch and uncommenting
private-bin-no-local nodidn't help. I also tried setting it to yes.Commenting the
private-tmponly helped if I remove the--started-from-filefrom the launch properties.EDIT: Removing
--started-from-filefrom KDE's launch properties does make VLC start normally and it actually adds that part automatically:Not that editing that command wasn't necessary.
@netblue30 commented on GitHub (Oct 6, 2016):
In a text editor open /etc/firejail/vlc.profile and comment out (add a #) the lines there one by one and try vlc again. Probably one of the include lines is creating the problem. I think one of the blacklists in one of the files is creating the problem.
@mr-blobbyyy commented on GitHub (Oct 15, 2016):
Wasn't the advice to leave that line indeed commented out?
Yep, and for me (v0.9.42), "private-tmp" was the very last line 😅
My exec path for "vlc" is this: "vlc --started-from-file %U" for the vlc.desktop file in ~/.local/share/applications/. Here's a swift guide @netblue30 (and others) might reference on the LM forums (in case you already didn't know): https://forums.linuxmint.com/viewtopic.php?p=1165909#p1165909
@chiraag-nataraj commented on GitHub (Aug 19, 2018):
Is this still an issue?
@chiraag-nataraj commented on GitHub (Aug 19, 2018):
Seems to work on my end. Going to close this, but @amarildojr and @mr-blobbyyy, please feel free to re-open if it's still an issue.
@GM-Script-Writer-62850 commented on GitHub (Mar 3, 2019):
I am suddenly about to reproduce this
xubunut 18.04 64bit
tried reinstalling some parts of VLC tried deleting
~/.cache/vlc, tried deleting~/.config/vlc, tried deleting~/.local/share/vlcnone of this solved the issue
@Necktwi commented on GitHub (Apr 14, 2020):
what does
--started-from-file %Uoption do? previously thevlc.desktopworked fine but now it won't startvlc@0xc0d commented on GitHub (May 24, 2020):
you just need to delete
--started-from-filein/usr/share/applications/vlc.desktopsomething like this:
Exec=/usr/bin/vlc %Uwill be fine@rusty-snake commented on GitHub (May 24, 2020):
Reopening for now. But I can not reproduce this yet.
vlc --full-help:@b1zzu commented on GitHub (May 28, 2020):
Same here the
/usr/bin/vlc --started-from-filedoesn't stat VLC, I had to manually fix the .desktop fileOS: Fedora 32
VLC media player 3.0.10 Vetinari (revision 3.0.10-0-g7f145afa84)
@rusty-snake commented on GitHub (May 29, 2020):
Looks like one off you must comment vlc.profile and uncomment line for line to try which is the problematic line.
@b1zzu commented on GitHub (May 29, 2020):
Hi @rusty-snake, I can't find the
vlc.profile@rusty-snake commented on GitHub (May 29, 2020):
Depending on how you installed firejail, but it should be under
/etc/firejail/vlc.profileor/usr/local/etc/firejail/vlc.profile.The easiest way is to copy it to .config/firejail where it will be automatical be loaded by firejail. Example:
After testing you can simple delete .config/firejail/vlc.profile.
@it9exm commented on GitHub (Jun 20, 2020):
Same here.
All of a sudden VLC is not starting when double clicking on files. It took a while to discover this was the cause, verified by launching it from a shell. Of course I tried to delete caches , and no, I don't have firejail. Does anybody know what caused this?
@mYnDstrEAm commented on GitHub (Jul 26, 2020):
I can play a file when I open it in VLC started with
firejail /usr/bin/vlc(using /etc/firejail/vlc.profile).I can play the file with right click->open with->VLC after having added firejail to the VLC application in Debian10/KDE like so:
firejail /usr/bin/vlc --started-from-file %U.But after something happened - and I don't know what - the file doesn't play anymore with the latter method while the former keeps working.
I then get these errors:
The latter error shows multiple times and also shows when using the former (working) method to open the file.
The file is still owned by my username.
Whatever is happening that causes the file to not play anymore might be related to library scanning by the Nuclear music player (the issue is linked above).
How to solve this problem?
@rusty-snake commented on GitHub (Jul 31, 2020):
Nobody know. I can not reproduce and other users have not found/reported a cause yet.
@mYnDstrEAm commented on GitHub (Aug 1, 2020):
I investigated further and the exact same file in one location does played when I select "Open with->VLC media player" and another one in another location didn't play when trying right afterwards. Both files have the same sha512sum and except of the directory-location exactly the same output when entering
ls -l filepath. I checked that the open with VLC media player made VLC start via firejail and that no other instance of VLC was running concurrently.And now I I've found the cause: it works when navigating to the directory directly but not when navigating to the directory via a symbolic link (pressing and holding ctrl+shift while dragging a folder in KDE or selecting "Link Here" after dragging it somewhere).
@rusty-snake commented on GitHub (Aug 4, 2020):
I tried with this and both ways work. Can you give some more detailed introductions to reproduce.
@mYnDstrEAm commented on GitHub (Aug 4, 2020):
These commands work on my machine as well (except for the stared->started typo in the 3rd).
The video also plays when creating a folder-link by dragging and choosing open with->VLC media player in KDE/Dolphin.
However playing the file doesn't work when the folder-link is placed onto the desktop.
Sorry for not testing / stating that it's working in some cases but not in some others (one at least).
So:
I get this error in the VLC media player every 2 seconds or so:
filesystem error: cannot open file /home/username/Desktop/Art/test.mp4 (Permission denied).cd ~/Desktop && firejail vlc --started-from-file ~/Desktop/Art-slnk/test.mp4@rusty-snake commented on GitHub (Aug 4, 2020):
@mYnDstrEAm commented on GitHub (Aug 4, 2020):
@rusty-snake commented on GitHub (Aug 4, 2020):
~/Folder/Art(as in 1) or./Art(as in 4)?lsalso.@mYnDstrEAm commented on GitHub (Aug 4, 2020):
@rusty-snake commented on GitHub (Aug 4, 2020):
@mYnDstrEAm commented on GitHub (Aug 4, 2020):
You're right, sorry. If you'd like to I could delete the previous comment and edit the post. It works for me as well. What doesn't work is placing the link on the desktop and then opening the file via this link. I could play audio and video files when the link is placed in Home, but not when it is placed onto the desktop.
Maybe it has to do with folder-restrictions of other running firejail instances even though I don't think that there's currently any with specific restrictions for the desktop folder and I haven't found any after shortly looking through the firejail profiles currently being used.
@rusty-snake commented on GitHub (Aug 4, 2020):
You can use
firejail --ignore=private-bin --profile=vlc bashto look around inside the sandbox.@mYnDstrEAm commented on GitHub (Aug 4, 2020):
The default VLC.profile does not have permissions for the desktop. It seems like the profile for VLC should not blacklist folders as restrictively as it does, and/or make it easy for users to specify which folders contain media files VLC should be able to run via a setup-prompt and/or prompts when trying to open files in other locations (a notification or message-box asking the user to whitelist the directory or file permanently or temporarily) and/or use the target locations for the blacklistings, not the links. For the VLC.profile in specific it might be useful to allow it read-access for all files (in all locations) of specific filetypes.
@rusty-snake commented on GitHub (Aug 4, 2020):
vlc.profile allows access to
${DESKTOP}, which firejail version do you use? Have you made any modifications to vlc.profile, disable-xdg.inc, vlc.local?@mYnDstrEAm commented on GitHub (Aug 4, 2020):
0.9.58.2 in Debian10 and I haven't modified (or created) these files.
If this is what caused the problem for the other users here and it has been resolved the issue could be closed. However, only allowing ${DESKTOP} might not solve all issues (I haven't checked if this problem still occurs for other locations) so I'd favor one of the suggestions I have made (for example prompting the user to allow access to a specific directory or all directories for specific filetypes if it gets a permission error). Furthermore, getting a newer version into the Debian repositories might also be good - that might be something mostly outside the scope of this project though.
@rusty-snake commented on GitHub (Aug 4, 2020):
unfortunately not possible
Use the one from the backports
@matu3ba commented on GitHub (Sep 8, 2020):
There is a new release planned.
@rusty-snake closing or would you prefer to adjust the bug template for symlink and permission stuff?