Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid download directory #27

Open
crivchri opened this issue Nov 23, 2018 · 16 comments
Open

Invalid download directory #27

crivchri opened this issue Nov 23, 2018 · 16 comments

Comments

@crivchri
Copy link

crivchri commented Nov 23, 2018

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
Copy link
Owner

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
Copy link
Author

crivchri commented Nov 23, 2018

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
Copy link
Owner

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
Copy link

ghost commented Dec 9, 2018

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
Copy link

ghost commented Dec 9, 2018

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
Copy link

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
Copy link

kea88 commented Dec 11, 2018

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
Copy link

jurek26 commented Jan 13, 2019

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
Copy link

quorn23 commented Mar 28, 2019

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
Copy link

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
Copy link
Owner

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

@beisat
Copy link

beisat commented May 2, 2019

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

@tanerceylan
Copy link

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
Copy link
Owner

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

@tanerceylan
Copy link

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

@chrischmx
Copy link

chrischmx commented Sep 13, 2020

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants