PlusMinus0 / headless-jd2-docker

Headless JDownloader 2 Docker Container
31 stars 38 forks source link

Invalid download directory #27

Open crivchri opened 5 years ago

crivchri commented 5 years ago

Hi,

Since a few releases (:latest) an error is returned for each download: "Invalid download directory".

I use Docker on Synology DS916+.

Thanks in advance and kind regards.

PlusMinus0 commented 5 years ago

Could you check the folder attributes on you NAS (ls -la) and check which user is running java in the container (docker top <name>).

crivchri commented 5 years ago

Hi,

Thanks for your answer.

Below the result of both commands:

root@jDownloader2-headless:/# ls -la
d---------   1 jdownloader users  176 Nov 22 09:25 downloads

docker top jDownloader2-headless
UID    PID      PPID     C    STIME    TTY       TIME        CMD
root   12645    12628    0    Nov22    pts/28    00:00:01    tini -g -- /opt/JDownloader/entrypoint.sh java -Djava.awt.headless=true -jar /opt/JDownloader/JDownloader.jar
root   12687    12645    0    Nov22    pts/28    00:00:00    /bin/sh /opt/JDownloader/entrypoint.sh java -Djava.awt.headless=true -jar /opt/JDownloader/JDownloader.jar
1000   12694    12687    0    Nov22    pts/28    00:02:05    java -Djava.awt.headless=true -jar /opt/JDownloader/JDownloader.jar
root   23392    23374    0    13:30    pts/33    00:00:00    /bin/bash

Kind regards

PlusMinus0 commented 5 years ago

The attributes are from within the container, right? Please print them from your host volume. In any case, there is obviously a problem with the attributes. It should be drwxrwxr-x or something like that (see chmod). Also, jd2 is run as UID 1000 that means the owner of your download directory should be the same (see chown).

ghost commented 5 years ago

Same issue here since pulling the latest image today, same permission-situation from within the docker container, I even am on the same synology-system. Reproducing: Creating a new directory, has been working with these permissions before grafik Gets mounted inside the container as follows: grafik jdownloader is indeed running as UID1000: grafik so seems like the folder just gets mounted with the wrong UID?

ghost commented 5 years ago

when I chown the directory to 1000, downloader is working as expected - but the permission is changed on the host system, not solely within the container. This does not feel like a final solution^^

MoshiMoshi0 commented 5 years ago

Had the same problem, setting uid and gid to 0 was the solution. It looks like the mounted volumes have root/root permissions but by default jd2 is run as jdownloader user so it has no access to cfg and downloads folders.

kea88 commented 5 years ago

Had the same problem, setting uid and gid to 0 was the solution. It looks like the mounted volumes have root/root permissions but by default jd2 is run as jdownloader user so it has no access to cfg and downloads folders.

It's not a solution. The problem is when you download with the root user (uid/gid 0), your files will be written as root and you can't edit the files or move, because your "normal" user is not a "root" user.

For me in OMV 4 it works with the default UID 1000 / GID 100 because my default user has that UID/GID.

Check your UID/GID with "id username" and chmod the mounted cfg folder.

jurek26 commented 5 years ago

hi I got the same problem how to fix ?

oot@plusminus-jdownloader2-headless1:/# ls -la
total 4
drwxr-xr-x 1 root root 184 Apr 3 2018 .
drwxr-xr-x 1 root root 184 Apr 3 2018 ..
-rwxr-xr-x 1 root root 0 Apr 3 2018 .dockerenv
drwxr-xr-x 1 root root 926 Mar 14 2018 bin
drwxr-xr-x 1 root root 0 Feb 23 2018 boot
drwxr-xr-x 5 root root 360 Jan 13 10:23 dev
lrwxrwxrwx 1 root root 33 Mar 14 2018 docker-java-home -> /usr/lib/jvm/java
-8-openjdk-amd64
drwxr-xr-x 1 root root 1584 Apr 3 2018 etc
drwxr-xr-x 1 root root 0 Feb 23 2018 home
drwxr-xr-x 1 root root 84 Mar 12 2018 lib
drwxr-xr-x 1 root root 40 Mar 12 2018 lib64
drwxr-xr-x 1 root root 0 Mar 12 2018 media
drwxr-xr-x 1 root root 0 Mar 12 2018 mnt
drwxr-xr-x 1 root root 22 Mar 30 2018 opt
dr-xr-xr-x 330 root root 0 Jan 13 10:23 proc
drwx------ 1 root root 30 Mar 12 2018 root
drwxr-xr-x 1 root root 26 Mar 12 2018 run
root@plusminus-jdownloader2-headless1:/#

quorn23 commented 5 years ago

Is this an issue that is still being worked on? In the current state the container is broken and not usable. Tested to run it with uid 0 (root) and not even running as root it works properly. The downloads end up in Nirvana.

phiberoptick commented 5 years ago

It has no issue reaching the config dir as it lives in /opt/JDownloader/ which has the proper owner/permissions for the "jdownloader" user.

jdownloader@94f2d1896756:/$ ls -al /opt/JDownloader/
total 12568
drwxr-xr-x 24 jdownloader users    4096 Apr  5 05:38 .
drwxr-xr-x  6 root        root     4096 Apr  5 05:15 ..
-rw-r--r--  1 jdownloader users 7957758 Apr  5 05:15 Core.jar
-rw-r--r--  1 jdownloader users       0 Apr  5 05:38 JD2.lock
-rw-r--r--  1 jdownloader users       4 Apr  5 05:38 JD2.port
-rw-r--r--  1 jdownloader users 3640229 Apr  5 05:15 JDownloader.jar
-rw-r--r--  1 jdownloader users       5 Apr  5 05:38 JDownloader.pid
-rw-r--r--  1 jdownloader users     320 Apr  5 05:15 build.json
drwxr-xr-x  4 jdownloader users   28672 Apr  5 05:38 cfg
-rwxr-xr-x  1 jdownloader users     668 Feb 17 22:42 entrypoint.sh
drwxr-xr-x  2 jdownloader users    4096 Apr  5 05:38 extensions
drwxr-xr-x  2 jdownloader users    4096 Apr  5 05:15 java
drwxr-xr-x  4 jdownloader users    4096 Apr  5 05:15 jd
drwxr-xr-x  8 jdownloader users    4096 Apr  5 05:15 libs
-rw-r--r--  1 jdownloader users   32034 Apr  5 05:15 license.txt
-rw-r--r--  1 jdownloader users   39624 Apr  5 05:15 license_german.txt
drwxr-xr-x  5 jdownloader users    4096 Apr  5 05:15 licenses
drwxr-xr-x 13 jdownloader users    4096 Apr  5 05:38 logs
-rw-r--r--  1 jdownloader users   72390 Feb 17 22:42 sevenzipjbinding1509.jar
-rw-r--r--  1 jdownloader users 1012515 Feb 17 22:42 sevenzipjbinding1509Linux.jar
drwxr-xr-x  3 jdownloader users    4096 Apr  5 05:15 themes
drwxr-xr-x  7 jdownloader users    4096 Apr  5 05:38 tmp
drwxr-xr-x  3 jdownloader users    4096 Apr  5 05:15 tools
drwxr-xr-x  5 jdownloader users    4096 Apr  5 05:15 translations
drwxr-xr-x  4 jdownloader users    4096 Apr  5 05:15 update
jdownloader@94f2d1896756:/$

The problem lies in the fact that the "Downloads" directory lives at /root/Downloads/ which in itself has the proper permissions on it. By default no user should have access to root's files so /root/ has pretty restrictive permissions. Specifically that is has a mode of "700" to only allow the user with uid "0" to read, write or execute under that dir.

root@94f2d1896756:~# ls -al /root
total 56
drwx------  3 root        root   4096 Apr  5 05:14 .
drwxr-xr-x 45 root        root   4096 Apr  5 05:15 ..
-rw-r--r--  1 root        root    570 Jan 31  2010 .bashrc
-rw-r--r--  1 root        root    148 Aug 17  2015 .profile
-rw-r--r--  1 root        root    209 Feb 17 22:48 .wget-hsts
drwxrwxr-x  2 jdownloader users 36864 Apr  5 05:40 Downloads
root@94f2d1896756:~#
jdownloader@94f2d1896756:/$ cd /root/Downloads
bash: cd: /root/Downloads: Permission denied
jdownloader@94f2d1896756:/$

If the image build is changed to create the Downloads directory as /opt/JDownloader/Downloads, there should be no issue. That should only require adding a line to the RUN command in the Dockerfile.

mkdir -p /opt/JDownloader/Downloads && \

Then just change the "org.jdownloader.settings.GeneralSettings.json" file to point to the new directory. Either by editing it manually/GUI or doing a search and replace in the Dockerfile or entrypoint.sh, etc/

"defaultdownloadfolder" : "/root/Downloads", to "defaultdownloadfolder" : "/opt/JDownloader/Downloads",

Could also put it in a script to run at start since the "jdownloader" user has sufficient permissions to both create the directory as well as edit the config file.

Of course, if you want to just be down and dirty cause you need some instant gratification, you can always modify the permissions at start. If you run a simple chmod 705 /root (as root) when the container starts (or after it starts), you're good to go.

jdownloader@94f2d1896756:/$ ls -al /root/Downloads/
total 40
drwxrwxr-x 2 jdownloader users 36864 Apr  5 05:40 .
drwx---r-x 3 root        root   4096 Apr  5 05:14 ..
jdownloader@94f2d1896756:/$ touch /root/Downloads/testing.somefile
jdownloader@94f2d1896756:/$ ls -al /root/Downloads/
total 40
drwxrwxr-x 2 jdownloader users 36864 Apr  5 06:45 .
drwx---r-x 3 root        root   4096 Apr  5 05:14 ..
-rw-r--r-- 1 jdownloader users     0 Apr  5 06:45 testing.somefile
jdownloader@94f2d1896756:/$ rm /root/Downloads/testing.somefile
jdownloader@94f2d1896756:/$ ls -al /root/Downloads/
total 40
drwxrwxr-x 2 jdownloader users 36864 Apr  5 06:45 .
drwx---r-x 3 root        root   4096 Apr  5 05:14 ..
jdownloader@94f2d1896756:/$

Hopefully this is helpful and sorry for being so long winded. In hindsight, I probably could've cloned, modfied and done a PR in less lines...LoLz

-Ronan

PlusMinus0 commented 5 years ago

Thank you for your input. As I'm currently moving, my server is offline atm. I'll have a look into it.

beisat commented 5 years ago

DL folder is now changed per default, but the instructions in readme still say to mount /downloads. Must mount /opt/JDownloader/Downloads

tanerceylan commented 4 years ago

Is this not fixed? Still getting the invalid directory message. Container is created with a PUID (1034), that has read/write permissions for the download directory. But Jdownloader is running with a PUID=1000.

PlusMinus0 commented 4 years ago

What’s your default Download path and how did you start the container? I still haven’t gotten to making it foolproof again.

tanerceylan commented 4 years ago

My bad. I created the container with „PUID“ instead of „UID“. I an an idiot 😬

chrischmx commented 4 years ago

@MoshiMoshi0 youre right. Setting GID and UID to 0 works also fine for me. I was not able to get it working with my own UID.

Thank you very much