Can someone help me please?
After every successful unrar Pyload .log is like:
DEBUG FileBot-Hook: MKV-Checkup (archive_extracted)
DEBUG Hier sind keine Archive
ERROR FileBot: [Errno 13] Permission denied
DEBUG All downloads finished
How can it be?
Config:
Synology 1813+ with enkidu package but user is root in start-stop-status start script.
The downloadpath as well as the filebot.py from GutzPilz also the filebot.sh with depending paths are 777
paths in the hook plugin are set correctly.
Hi, what do you mean by "output of call"?
FileBot is triggered by the filebot.py plugin from GutzPilz. I dont know where i can give pyload and filebot permissions for the pyload path and download path. Or is it something else?
Thanks! Now i'm 1 step closer. the symlink /usr/bin/filebot has root:root and 777, but the binary file /volume1/@appstore/filebot/FileBot.jar has root:root 622. After i chmod, the file is corrupted.
FileBot.jar is a jar file. Jar files are zip files, hence not executable. But since you made it executable your shell is now executing a zip file as if it was a shell script...
You will find the startup script somewhere in /volume1/@appstore/filebot/bin and it's gonna be an executable shell script.
Old but gold...
For the sake of completeness i solved the problem a view months ago, this is just for other users with the same problem.
The problem was not the shell script, i could call in a SSH-Session filebot manually but not via pyload and DSM Taskplanner (in a synology based system), so the difference is a PATH variable.
The only one which comes into question is the java path. The running shell knows where to find java, but pyload and DSM try's to find java in /usr/syno/bin/filebot
That is not the path for the oracle java package installed in /volume1/@appstore/java
A symlink (as you said, but my linux knowledge wasn't good enough) with chmod +x solved the problem, so pyload and DSM now finds java end executes filebot well.