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

rTorrent user & Webserver user cannot access... (synology, docker) #44

Open
defaultsecurity opened this issue Nov 28, 2017 · 11 comments
Open

Comments

@defaultsecurity
Copy link

defaultsecurity commented Nov 28, 2017

After creating the container with docker, I can launch ruTorrent, but with errors.

Using rtorrent-rutorrent:latest installed today.

Hardware: DS918+
Architecture: Apollo Lake

Synology Packages:

  • Apache HTTP Server 2.4
  • PHP 7.0
  • Web Station

ENV Settings from Docker:

  • PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • GRP_ID: set
  • USR_ID: set
  • NOIPV6: 1

Mount path "/downloads" set in Docker's volume settings

What is the Webserver user and the rTorrent user? Should I create new users for them in the synology settings? If yes, then what username/password?

LOG:
[28.11.2017 13:11:00] WebUI started.
[28.11.2017 13:11:00] Webserver user doesn't have read/write/execute access to the torrents directory. You cannot add torrents via ruTorrent. (/downloads/.rutorrent/torrents)
[28.11.2017 13:11:00] Webserver user doesn't have read/write/execute access to the settings directory. ruTorrent settings cannot be saved. (/downloads/.rutorrent/settings)
[28.11.2017 13:11:00] rTorrent user must have read/execute access to the torrents directory. You cannot add torrents via ruTorrent. (/downloads/.rutorrent/torrents)
[28.11.2017 13:11:00] rTorrent user must have read/write/execute access to the settings directory. (/downloads/.rutorrent/settings)
[28.11.2017 13:11:00] rutracker_check: Plugin will not work. Webserver user must have execute access to the rtorrent session directory (/downloads/.rtorrent/session/).
[28.11.2017 13:11:00] _task: Some functionality will be unavailable. rTorrent user can't access external program (pgrep).
[28.11.2017 13:11:00] autotools: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] create: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] datadir: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] history: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] loginmgr: Some functionality will be unavailable. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] ratio: Some functionality will be unavailable. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] retrackers: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] rss: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] rutracker_check: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] scheduler: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] trafic: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] unpack: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] xmpp: Plugin will not work. rTorrent user can't access external program (php).
[28.11.2017 13:11:00] mediainfo: Plugin will not work. rTorrent user can't access external program (mediainfo).
[28.11.2017 13:11:00] rss: Some functionality will be unavailable. rTorrent user can't access external program (curl).
[28.11.2017 13:11:00] screenshots: Plugin will not work. rTorrent user can't access external program (ffmpeg).
[28.11.2017 13:11:00] spectrogram: Plugin will not work. rTorrent user can't access external program (sox).

The folders logged above all exist.

@bille747
Copy link

bille747 commented Dec 4, 2017

Having the same issue here on my synology box. Have you found a solution?

@defaultsecurity
Copy link
Author

Nope, sorry. I tried everything I could think of. I'm clueless.

@pboiseau
Copy link

Which USR_ID and GRP_ID did you set ?

@codevski
Copy link

I'm actually running into the same issue, are those USR ID and GRP ID even mapped properly? using same ID for all linuxserver docker files and this is the only one that doesnt seem to work correctly...

@richardpowellus
Copy link

Did anyone solve this issue? I'm having the same issue on my Synology NAS. I'm using UID=1029, GID=100. The UID has full read/write to the folder I mapped to /downloads.

@JohnDoee
Copy link

JohnDoee commented Nov 7, 2018

I had the same issue, although not on on a Synology. I fixed it by doing chown -R 1000:1000 /path/to/downloadon the host machine. Those are default UID/GID.

@defaultsecurity
Copy link
Author

I just tried again right now, but still couldn't solve it. I've set up GRP_ID and USR_ID properly. I'm getting the same permission errors. The linuxserver/rutorrent container is working properly, so it couldn't be that hard to fix. I'd rather use this image because of autodl-irssi.

@spoooyders
Copy link

spoooyders commented Dec 11, 2022

Sorry for necromancy, but I think I've found a root cause of this.

There are really two users inside of the container:

  • USR_ID:GRP_ID - used for rtorrent
  • nginx:nginx - used for nginx
    In case if /downloads has USR_ID:GRP_ID ownership with 700 permissions (in my case it was by default) nginx user can't access that directory (despite what /downloads/.rutorrent is owned by nginx:nginx).
    And to fix it you need to do this:
chmod o+rx /path/to/download

@halilnevzat
Copy link

Sorry for necromancy, but I think I've found a root cause of this.

There are really two users inside of the container:

  • USR_ID:GRP_ID - used for rtorrent
  • nginx:nginx - used for nginx
    In case if /downloads has USR_ID:GRP_ID ownership with 700 permissions (in my case it was by default) nginx user can't access that directory (despite what /downloads/.rutorrent is owned by nginx:nginx).
    And to fix it you need to do this:
chmod o+rx /path/to/download

in my case there was no torrent directory at all, i created the torrent directory manually and it worked.

@fmiguelmmartins
Copy link

fmiguelmmartins commented May 16, 2023

Sorry for necromancy, but I think I've found a root cause of this.

There are really two users inside of the container:

  • USR_ID:GRP_ID - used for rtorrent
  • nginx:nginx - used for nginx
    In case if /downloads has USR_ID:GRP_ID ownership with 700 permissions (in my case it was by default) nginx user can't access that directory (despite what /downloads/.rutorrent is owned by nginx:nginx).
    And to fix it you need to do this:
chmod o+rx /path/to/download

I think that is the exact problem because rutorrent manages to create the folders it needs, however the webserver doesn't have access to read it (i.e nginx). @spoooyders when you say chmod path to download, do you mean inside the container or the mount folder on the host? I tried that chmod on the host but didn't work.

Btw, this problem only happens for me on my NAS smb share mount folder, if I pick a local folder, it works flawlessly

@spoooyders
Copy link

@fmiguelmmartins on the host.

Compose file:

  rtorrent-rutorrent:
    image: diameter/rtorrent-rutorrent:latest-alpine
    volumes:
      - /home/user1/downloads:/downloads

Permissions:

>ls -lad /home/user1/downloads/
drwxr-xr-x 6 user1 user1 4096 Dec 11  2022 /home/user1/downloads/

So in my case it is 755 mode for downloads directory, but really 705 should be enough.

Inside the container:

>docker exec -it rutorrent_rtorrent-rutorrent_1 /bin/sh
/ # ls -lad /downloads
drwxr-xr-x    6 rtorrent rtorrent      4096 Dec 11  2022 /downloads

^ Note same 755 mode in a container, which is good.

/ # su -s /bin/sh nginx
/ $ id
uid=100(nginx) gid=101(nginx) groups=82(www-data),101(nginx),101(nginx)
/ $ ls -la /downloads/.rutorrent/
total 24
drwxrwxrwx    5 nginx    nginx         4096 Dec 11  2022 .
drwxr-xr-x    6 rtorrent rtorrent      4096 Dec 11  2022 ..
-rw-rw-rw-    1 nginx    nginx         1879 Dec 11  2022 errors.log
drwxrwxrwx    6 nginx    nginx         4096 Jul  1 11:34 settings
drwxr-xr-x    2 nginx    nginx         4096 Dec 11  2022 torrents
drwxrwxrwx    3 nginx    nginx         4096 Dec 11  2022 users

As you see nginx user can access downloads directory without issues.

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

9 participants