Page 1 of 1
java.nio.file.NoSuchFileException
Posted: 30 Sep 2017, 19:18
by TempleClause
I updated to the newest filebot (4.7.9) and now filebot is not working for me anymore.
I installed it via snap. Before it was a standard apt-get package.
I always get this error:
Code: Select all
Illegal Argument: java.nio.file.NoSuchFileException:
I call filebot like this:
Code: Select all
filebot -rename -r "$extractedPath" --db TheMovieDB --format "$pattern" --action move --conflict override -non-strict
Before this was working just fine and now I always get the file not found exception.
What am I missing?
Thanks
Re: java.nio.file.NoSuchFileException
Posted: 30 Sep 2017, 21:05
by rednoah
What is the value of
$extractedPath when you call
filebot?
Use
set -xu if you're not sure what you're doing:
Re: java.nio.file.NoSuchFileException
Posted: 30 Sep 2017, 23:36
by TempleClause
rednoah wrote: ↑30 Sep 2017, 21:05
What is the value of
$extractedPath when you call
filebot?
Use
set -xu if you're not sure what you're doing:
$extractedPath is the path to the directory ->/data/Downloads/Movies/Extracted/
What does
do?
Odly enough I also tried to do this:
Code: Select all
filebot -mediainfo /path/I/am/100%/sure/it/exists.mkv --format {json}
And it also gives me a file not found exception :-/
Re: java.nio.file.NoSuchFileException
Posted: 01 Oct 2017, 05:37
by rednoah
If you're 100% sure that the path exists, then it's possible that it's just not accessible / visible to FileBot due to permissions.
Re: java.nio.file.NoSuchFileException
Posted: 01 Oct 2017, 18:16
by TempleClause
You are right, it is indeed some kind of permission issue but I don't know how to resolve it.
The files are on my secondary hard drive which are mounted to /data/.
If I copy my test file to the Desktop it works fine.
I tried this:
Code: Select all
sudo snap connect filebot:removable-media
As well as installing filebot with the devmode like this:
Code: Select all
sudo snap install filebot --devmode
What else can I do?
Re: java.nio.file.NoSuchFileException
Posted: 03 Oct 2017, 20:43
by TempleClause
Is there a way to install a standard debian package instead of this snap stuff?
Re: java.nio.file.NoSuchFileException
Posted: 08 Jan 2018, 18:09
by kodiuser
I had the same error using a snap, but I was using the /tmp folder. After I started using another folder (for example ~/Desktop) the error was gone.
Re: java.nio.file.NoSuchFileException
Posted: 20 Feb 2018, 21:02
by maeldc
Hi, I've got the same issue and after some poking I believe it's due to the way snap handles permissions. snap puts filebot in a jail, this causes problems when you want to access network shares, or in my case files that are owned by another user but have read-write permissions for world.
It won't even let you access files that you own in /tmp, which is really odd. The only place I have found that works is under my home directory. None of my media is here
I suspect this is also why the filebot GUI does not work over X.
Someone asked above if there is a way to install just a debian package instead of using snap. Is this an option? I couldn't find one. I believe this would solve the issue.
I also tried installing filebot in snap "classic" mode which supposedly removes the jail. This doesn't make any difference.
EDIT: I looked a little farther, and also read the post on granting access to /media. My media is not under /media, it's under /share (I tried symbolic links from /media/share to /share - no joy).
If the developers want to continue using snap, please consider building a snap package that can be installed in "classic" mode. Apparently "classic" mode removes the sandbox/jail and allows the snap-deployed application to access the filesystem. Without classic, we're limited to using filebot only on files under our home directory, or under /media after running the "connect removable media" commands.
There is some discussion here explaining that tools that need access to the filesystem, like text editors, should be packaged in "classic" mode. filebot definitely falls into this category IMHO. [feel free to ignore the political discussions around the bad or good of snap]
https://www.reddit.com/r/Ubuntu/comment ... ally_hurt/
Re: java.nio.file.NoSuchFileException
Posted: 21 Feb 2018, 02:08
by rednoah
rednoah wrote: ↑21 Jun 2017, 16:36
By default, SNAP packages are not allowed to access
/media. The SNAP sandbox will deny access unless you have explicitly granted access to
removable-media.
Grant access to
removable-media if you want to process files in the
/media folder with FileBot:
Code: Select all
sudo snap connect filebot:removable-media
@see
https://github.com/snapcore/snapd/wiki/Interfaces
If you want to give a snap application full access to your system
(e.g. /mnt) then you can use
--devmode when installing the application to disable confinement entirely.
Have you tried this? Have you tried
--devmode to run the snap without confinement?
Re: java.nio.file.NoSuchFileException
Posted: 21 Feb 2018, 13:22
by maeldc
Have you tried this? Have you tried --devmode to run the snap without confinement?
Yes. It doesn't allow access to the whole filesystem. I have tried installation several times with the following flags:
(none)
--classic
--devmode
They all have the same behavior, only allowing operations on files under my home directory or /media. I ran this command yesterday:
Code: Select all
sudo snap connect filebot:removable-media
snap seems to remember this setting across remove/install operations, so this is why /media is allowed.
I also see that "home" is allowed by default after installation (from "snap interfaces" command)
With --devmode I saw the following in syslog:
Code: Select all
Feb 21 05:39:36 yoda kernel: [52308.970604] audit: type=1400 audit(1519209576.16
9:89): apparmor="ALLOWED" operation="open" profile="snap.filebot.filebot" name="
/mnt/" pid=22304 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=
0
Feb 21 05:39:36 yoda kernel: [52308.971020] audit: type=1400 audit(1519209576.16
9:90): apparmor="ALLOWED" operation="open" profile="snap.filebot.filebot" name="
/media/" pid=22304 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 oui
d=0
I didn't see any denials logged, and as noted files under /mnt are not able to be processed by filebot.
I found some documentation here:
https://docs.snapcraft.io/reference/confinement
It's a little unclear, but it seems to indicate that "--classic" install won't do anything unless the package was built with classic confinement capability.
Re: java.nio.file.NoSuchFileException
Posted: 05 Dec 2018, 01:36
by kheaactua
Will this ever be fixed? I'm reluctant to buy a license when I have to run a script to store my files on /tmp, run filebot, and then rsync the results to my media drive. Is there any better way?
Re: java.nio.file.NoSuchFileException
Posted: 05 Dec 2018, 07:09
by rednoah
Just use the classic
deb package to
avoid snap confinement altogether.
Illegal Argument: java.nio.file.NoSuchFileException has been fixed, and should give you a better error message now. If the system doesn't allow file access, then the correct behaviour is a failure. That being said, if
snap confinement is an issue, then you can just use the
deb instead, which then runs with your permissions as usual.
Re: java.nio.file.NoSuchFileException
Posted: 07 Dec 2018, 14:11
by kheaactua
nice, thanks, I'll give it a try.