Docker-transmission-openvpn: transmission.log Permission denied

Created on 29 Nov 2017 · 14Comments · Source: haugene/docker-transmission-openvpn

If PUID and PGID are set in the env (aka not running as root), then there is a permissions error on transmission.log

Unsetting PUID and PGID allows it to work fine

NOTE: These logs are in reverse order for some reason (Newest at the top)

date | stream | content
-- | -- | --
2017-11-29 04:45:53 | stderr | [2017-11-29 04:45:53.444] transmission-remote:  (http://localhost:9091/transmission/rpc/) Couldn't connect to server
2017-11-29 04:45:43 | stdout | Checking port...
2017-11-29 04:45:43 | stderr | [2017-11-29 04:45:43.422] transmission-remote:  (http://localhost:9091/transmission/rpc/) Couldn't connect to server
2017-11-29 04:45:43 | stderr | [2017-11-29 04:45:43.401] transmission-remote:  (http://localhost:9091/transmission/rpc/) Couldn't connect to server
2017-11-29 04:45:43 | stdout | transmission auth not required
2017-11-29 04:45:43 | stdout | Got new port 27406 from PIA
2017-11-29 04:45:42 | stderr | Couldn't (re)open log file "/data/transmission-home/transmission.log": Permission denied
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 Initialization Sequence Completed
2017-11-29 04:45:42 | stdout | Generating new client id for PIA
2017-11-29 04:45:42 | stdout | Transmission startup script complete.
2017-11-29 04:45:42 | stdout | CONFIGURING PORT FORWARDING
2017-11-29 04:45:42 | stdout | STARTING TRANSMISSION
2017-11-29 04:45:42 | stdout |
2017-11-29 04:45:42 | stdout | -------------------------------------
2017-11-29 04:45:42 | stdout | User gid:    100
2017-11-29 04:45:42 | stdout | User uid:    1234
2017-11-29 04:45:42 | stdout | User name:   abc
2017-11-29 04:45:42 | stdout | -------------------------------------
2017-11-29 04:45:42 | stdout | Transmission will run as
2017-11-29 04:45:42 | stdout | -------------------------------------
2017-11-29 04:45:42 | stdout |
2017-11-29 04:45:42 | stdout | Setting owner for transmission paths to 1234:100
2017-11-29 04:45:42 | stdout | Generating transmission settings.json from env variables
2017-11-29 04:45:42 | stdout | Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.25.10.6
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 /etc/transmission/start.sh tun0 1500 1558 10.25.10.6 10.25.10.5 init
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 /sbin/ip addr add dev tun0 local 10.25.10.6 peer 10.25.10.5
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 /sbin/ip link set dev tun0 up mtu 1500
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2017-11-29 04:45:42 | stdout | Wed Nov 29 04:45:42 2017 TUN/TAP device tun0 opened
2017-11-29 04:45:41 | stdout | Wed Nov 29 04:45:41 2017 [7d1d5b6aeacc60eec581fc41cc82537a] Peer Connection Initiated with [AF_INET]172.98.67.32:1198
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 UDP link remote: [AF_INET]172.98.67.32:1198
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 UDP link local: (not bound)
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.32:1198
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
2017-11-29 04:45:40 | stdout | Wed Nov 29 04:45:40 2017 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
2017-11-29 04:45:40 | stdout | adding route to local network 192.168.1.0/24 via 172.17.0.1 dev eth0
2017-11-29 04:45:40 | stdout | Setting OPENVPN credentials...
2017-11-29 04:45:40 | stdout | Starting OpenVPN using config CA Toronto.ovpn
2017-11-29 04:45:40 | stdout | Using OpenVPN provider: PIA

Source

skylarmb

Most helpful comment

I would suggest that you check the permissions of the parent folders.

If for example you have this directory tree:
/mnt/transmission/transmission-home

then both /mnt and /mnt/transmission should have at least execute rights for others (chmod o+x) in case they belong to other users/groups or not.

ghost on 18 Dec 2017

👍3

All 14 comments

If you've ever run the container as root (without the PUID/PGID variables) then the log will have been created as root. Have you deleted the directory in the meantime, or chown'ed it?

haugene on 29 Nov 2017

@haugene yes, I tried deleting the directory completely and letting the container rebuild it. The result is the transmission-home directory being created and settings.json being created inside it just fine, both correctly owned by the PUID/PGID specified, but this error still occurs and no transmission.log file is created.

skylarmb on 30 Nov 2017

Hmm. And if you create the log file manually, chown it, and then start the container? Shouldn't be necessary of course, just checking.

haugene on 30 Nov 2017

@haugene Sorry, just seeing this. I don't know how to get a shell in my docker container as this other non-root user if that is what you are asking me to do, but I did try creating the file as root and then changing ownership with chown <user>:<group> transmission.log. Didn't seem to make a difference.

skylarmb on 8 Dec 2017

When you create your container, instead of binding /data folder as whole -v /YOUR_DOWNLOAD:/data, try binding the subfolder of /data, such as -v /YOUR_DOWNLOAD/complete:/data/completedand/or -v /YOUR_DOWNLOAD/complete:/data/incomplete(if you use incomplete folder). Then docker will create virtual volume (/date) with symlinks to your local download folder and transmission-home folder with necessary files with given PUID and PGID.
It makes more tricky to get to the transmission-home folder, but it works for me since I've never needed to access transmission-home so far.

funaz on 16 Dec 2017

I would suggest that you check the permissions of the parent folders.

If for example you have this directory tree:
/mnt/transmission/transmission-home

then both /mnt and /mnt/transmission should have at least execute rights for others (chmod o+x) in case they belong to other users/groups or not.

ghost on 18 Dec 2017

👍3

Did you solve this?

deten on 26 Jan 2018

Continuing on the comment on parent folders. That might be a thing here, depending on how transmission accesses it. So we're running chown on transmission-home, config and the completed, watch and incomplete directories. The linked issue #411 also has an error that a couple of these folders don't exist.

Linux permissions isn't always straight forward to say the least. But if the root folder /data is not chown'ed then then that might stop transmission from traversing that tree. So maybe we should do a chown -R on /config and /data and see if that resolves it.

You could try to exec in as root and do that recursive chown on /data manually to see if that resolves it.

haugene on 26 Jan 2018

haugene heres what I see regarding folder ownership:

-v /volume2/Transmission/:/data \

Owned by PUID 1026 & PGID 100

-v /volume2/Transmission/tun/resolv.conf:/etc/resolv.conf \

tun owned by PUID 1026 & PGID 100

-v /volume2/video/downloads/:/media \

video folder owned by PUID root & PGID 100
downloads folder owned by PUID 1026 & PGID 100

My Transmission is running as PUID 1026 & PGID 100. But it is not able to create the proper files within the Transmission folder. If I run as root, then it creates files as root.

Edit:

So I chowned the "video" folder recursively to 1026:100 but Transmission still wont create the files it needs running at 1026:100

Could this be something at all to do with the Username "abc"?

OR could Transmission startup be trying to create files as ROOT but since its running as 1026:100 its getting denied and angry?

Okay I tried again using root and it creates files but when Sonarr tries to transfer the file to the /tv/ folder it says "No files found are eligible for import in /media/".

Sonarr has no /media/ folder. So it must be reading that from Transmission. Do I need Transmission and Sonarr to have a /media folder?

* Update *
Okay, so I solved this problem. I had to add a volume to SONARR that was the same path and name as TRANSMISSION /media.

This still doesn't answer why I have to run as root to get Transmission working. But this is good news!

Last item on my list here. Sonarr is not able to communicate with transmission for some reason.

Unable to communicate with Transmission. Cannot access a disposed object. Object name: 'System.Net.Sockets.NetworkStream'.

deten on 27 Jan 2018

To answer your questions. 1. Username doesn't matter, that's relative to the running system and it's only UID/GID that is evaluated. 2. If it is trying to create files as root, that would always work even if it's owned by whoever.

You're running sonarr as a container, right? And also as the same user? Because you could use the --volumes-from=openvpn-container and they would share volumes. And if you're running sonarr as a container, how are you addressing the openvpn container. It wont be localhost:9091. You then need to link it and use the link name, or run sonarr in host networking mode.

haugene on 27 Jan 2018

Because you could use the --volumes-from=openvpn-container

Can you elaborate on how I would implement this?

I am running both Sonarr and Transmission in docker as containers. I originally had them as same user. Now I am running transmission without PUID/PGID and it runs as root. Hence the solution above.

My Transmission container is accessed at 192.168.29.223:9091, my Sonarr at 192.168.29.223:8989. When Sonarr restarts I have an issue but if I "test" the connection it resolves and starts controlling torrents again.

I will check out host networking mode.

Finally, I noticed that my peer port is "closed" in Transmission. Any solution for this?

Tusen Takk for hjelpen!

deten on 27 Jan 2018

😄1

You're welcome ;) Sorry it took a while before I got back to you, but...

The "permission denied" and ownership issues might be resolved in #423 where we're also changing ownership of transmission_home. Can you try pulling and using the dev tag and see if it's resolved?

As for the --volumes-from option. That's basically it. If you have a container that has some volumes, another container can be started with --volumes-from= and it will also have all volumes from that container and they can share that storage. See https://docs.docker.com/engine/reference/commandline/run/

haugene on 11 Mar 2018

423 merged to master, closing this

haugene on 8 Apr 2018

🎉1 👍1

I had the same issue (all directories and file would be successfully created by the container, but it would then fails with "permission denied" for the transmission.log file...) and I fixed it by correcting the permissions of the data directory. For some reasons, it was:
d---------+ 1 root root
and I changed it to
drwxr-xr-x 1 root root
which solved the issue.