Docker Transmission Error

Currently reading
Docker Transmission Error

248
15
Operating system
  1. macOS
Mobile operating system
  1. iOS
Last edited:
version: "2.4" is the first line of compose file, which works for sonarr/radarr etc, and guessing might be the glitch for Transmission.

Deployment error
1629594821734.png


Docker compose
[Code}
version: "2.4"
services:
[/CODE]


Code:
transmission:
    image: linuxserver/transmission:latest
    restart: always
    container_name: transmission-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/transmission:/media-store/transmission:rw
      - /volume1/docker/media-center-config/transmission:/config:rw
    networks:
      default: {}
    ports:
      - 9091:9091

If that Transmission block is removed from the compose, everything works as expected.
 
k. As I understand, there were problems w/docker and other apps being broken through dsm7 and recommended to stick w/2.4
1629601860512.png
 
Last edited:
That's fine. Change the 3.3 to the level you prefer.
Recommendation was 2.4, but that was then flagging the error w/Transmission
-- post merged: --

placing transmission at the top does appear to not flag errors.
regardless of the version number, transmission is not happening...

1629603791161.png


Code:
version: "3.0"
services:
  transmission:
    image: linuxserver/transmission:latest
    restart: always
    container_name: transmission-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/transmission:/media-store/raw:rw
      - /volume1//docker/media-center-config/transmission/config:rw
    networks:
      default: {}
    ports:
      - 9091:9091

  sonarr:
    image: linuxserver/sonarr:latest
    restart: always
    container_name: sonarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/sonarr:/media-store/sonarr:rw
      - /volume1/docker/media-center-config/sonarr:/config:rw
    networks:
      default: {}
    ports:
      - 8989:8989

  radarr:
    image: linuxserver/radarr:latest
    restart: always
    container_name: radarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/radarr:/media-store/radarr:rw
      - /volume1/docker/media-center-config/radarr:/config:rw
    networks:
      default: {}
    ports:
      - 7878:7878

  jackett:
    image: linuxserver/jackett:latest
    restart: always
    container_name: jackett-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/jackett:/media-store/jackett:rw
      - /volume1/docker/media-center-config/jackett:/config:rw
    networks:
      default: {}
    ports:
      - 9117:9117

  lidarr:
    image: linuxserver/lidarr:latest
    restart: always
    container_name: lidarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/lidarr:rw
      - /volume1/docker/media-center-config/lidarr:/config:rw
    networks:
      default: {}
    ports:
      - 8686:8686

  couchpotato:
    image: linuxserver/couchpotato:latest
    restart: always
    container_name: couchpotato-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/couchpotato:rw
      - /volume1/docker/media-center-config/couchpotato:/config:rw
    networks:
      default: {}
    ports:
      - 5050:5050

networks:
  default:
    name: media-stack2
[ICODE]
 
Last edited:
From the error you shared, the issue was that you had either and indention problem. Yaml builds its semantical strucuture by indentions, which must be done with 2 or 4 space characters.
-- post merged: --

That's fine. Change the 3.3 to the level you prefer.
I am not sure if this a recommendation it is wise blindly to folow.

There is exactly one usecase where it makes sense to use the latest 3.x schema version: when you need to use "secrets" in your container, which is its ow top level configuration item. If secrets are not used, then 3.x breaks use cases because many low level settings are moved underneath the "deploy" item, which is ignored for docker-compose deployments. It shouldn't matter if only the "basic settings" are used. Feel free to compare version 2 and version 3 specs to see what I mean. Things should be done with a reason, shouldn't they.

Thus, said: Just because I know that using a 2.4 spec is the better choice, doesn't mean other versions don't work for you. Use whatever is wors best for you :)
 
Last edited:
From the error you shared, the issue was that you had either and indention problem. Yaml builds its semantical strucuture by indentions, which must be done with 2 or 4 space characters.
-- post merged: --


I am not sure if this a recommendation it is wise blindly to folow.

There is exactly one usecase where it makes sense to use the latest 3.x schema version: when you need to use "secrets" in your container, which is its ow top level configuration item. If secrets are not used, then 3.x breaks use cases because many low level settings are moved underneath the "deploy" item, which is ignored for docker-compose deployments. It shouldn't matter if only the "basic settings" are used. Feel free to compare version 2 and version 3 specs to see what I mean. Things should be done with a reason, shouldn't they.

Thus, said: Just because I know that using a 2.4 spec is the better choice, doesn't mean other versions don't work for you. Use whatever is wors best for you :)

• Deploy error stopped when Transmission was moved to position 1 in the service stack sequence.
• Double checked the indendentations which appear accurate.
• Deployment happens w/o error, and Transmission does not show anywhere in the list of deployed services.
• Version back to 2.4

Fresh images / container data...

Code:
version: "2.4"
services:

  transmission:
    image: linuxserver/transmission:latest
    restart: always
    container_name: transmission-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/raw:/media-store/raw:rw
      - /volume1//docker/media-center-config/transmission/config:rw
    networks:
      default: {}
    ports:
      - 9091:9091

  sonarr:
    image: linuxserver/sonarr:latest
    restart: always
    container_name: sonarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/sonarr:/media-store/sonarr:rw
      - /volume1/docker/media-center-config/sonarr:/config:rw
    networks:
      default: {}
    ports:
      - 8989:8989

  radarr:
    image: linuxserver/radarr:latest
    restart: always
    container_name: radarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/radarr:/media-store/radarr:rw
      - /volume1/docker/media-center-config/radarr:/config:rw
    networks:
      default: {}
    ports:
      - 7878:7878

  jackett:
    image: linuxserver/jackett:latest
    restart: always
    container_name: jackett-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/jackett:/media-store/jackett:rw
      - /volume1/docker/media-center-config/jackett:/config:rw
    networks:
      default: {}
    ports:
      - 9117:9117

  lidarr:
    image: linuxserver/lidarr:latest
    restart: always
    container_name: lidarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/lidarr:rw
      - /volume1/docker/media-center-config/lidarr:/config:rw
    networks:
      default: {}
    ports:
      - 8686:8686

  couchpotato:
    image: linuxserver/couchpotato:latest
    restart: always
    container_name: couchpotato-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/couchpotato:rw
      - /volume1/docker/media-center-config/couchpotato:/config:rw
    networks:
      default: {}
    ports:
      - 5050:5050

networks:
  default:
    name: media-stack2

Internal IPs sequence from 0.2 - 0.6. Curious if 0.1 is assigned to Transmission?

How do you look up error codes that vanished too quickly? I am currently grabbing errors by deleting everything, recreating and waiting for error to take a screen shot to then open and review...


--------------------------
Moving Transmission to the bottom of the service sequence, errors again appear. Indentation matches other working code.
Errors are indicating a problem w/the baths for Transmission.

Note by the code that the paths are identical to the pathing sequence for the other services, all the same except folder name.



1629628485118.png
1629628595495.png
1629628626939.png
 
(think) I don't see a reason why the transmission service is not visible.

the x.x.x.1 ip is typicaly the gateway of the (docker) network.

One more thing: whatever you do, do not use the container ip's to communicate amongst the containers, as they will eventualy change. For the sake of reliability, it is recommended to use service names (in your case transmission, couchpotato, jackett, ... ) instead (=leverage service discovery).
 
UPDATE:

Removed the :rw from Transmission paths and Transmission is now properly deploying.
@one-eyed-king Presuming /rw would be read write permissions and wondering why that same model would be throwing errors for Transmission but not the other services?
 
(think) I don't see a reason why the transmission service is not visible.

the x.x.x.1 ip is typicaly the gateway of the (docker) network.

One more thing: whatever you do, do not use the container ip's to communicate amongst the containers, as they will eventualy change. For the sake of reliability, it is recommended to use service names (in your case transmission, couchpotato, jackett, ... ) instead (=leverage service discovery).
Not following, as I do not recall editing IP's or service names...everything is there in the docker compose.
 
yup. Left hand side before the colon = host side; Right hand side after the colon = container side, value after the optional last colon specifies bind-mount permissions (when provided, default is rw) , there are others then ro and rw, but those are for more advanced use cases, e.g. when selinux is activated on the host (which is not the case on syno).
 
yup. Left hand side before the colon = host side; Right hand side after the colon = container side, value after the optional last colon specifies bind-mount permissions (when provided, default is rw) , there are others then ro and rw, but those are for more advanced use cases, e.g. when selinux is activated on the host (which is not the case on syno).
adding back the :rw results again in no deployment errors and no Transmission deployed.

Code:
version: "2.4"
services:

  sonarr:
    image: linuxserver/sonarr:latest
    restart: always
    container_name: sonarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/sonarr:/media-store/sonarr:rw
      - /volume1/docker/media-center-config/sonarr:/config:rw
    networks:
      default: {}
    ports:
      - 8989:8989

  radarr:
    image: linuxserver/radarr:latest
    restart: always
    container_name: radarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/radarr:/media-store/radarr:rw
      - /volume1/docker/media-center-config/radarr:/config:rw
    networks:
      default: {}
    ports:
      - 7878:7878

  jackett:
    image: linuxserver/jackett:latest
    restart: always
    container_name: jackett-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/jackett:/media-store/jackett:rw
      - /volume1/docker/media-center-config/jackett:/config:rw
    networks:
      default: {}
    ports:
      - 9117:9117

  lidarr:
    image: linuxserver/lidarr:latest
    restart: always
    container_name: lidarr-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/lidarr:rw
      - /volume1/docker/media-center-config/lidarr:/config:rw
    networks:
      default: {}
    ports:
      - 8686:8686

  couchpotato:
    image: linuxserver/couchpotato:latest
    restart: always
    container_name: couchpotato-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/lidarr:/media-store/couchpotato:rw
      - /volume1/docker/media-center-config/couchpotato:/config:rw
    networks:
      default: {}
    ports:
      - 5050:5050

  transmission:
    image: linuxserver/transmission:latest
    restart: always
    container_name: transmission-stack2
    environment:
      - PGID=100
      - PUID=1032
    volumes:
      - /volumeUSB1/usbshare/raw:/media-store/raw:rw
      - /volume1/docker/media-center-config/transmission/config:rw
    networks:
      default: {}
    ports:
      - 9091:9091

networks:
  default:
    name: media-stack2

[CODE]

[ATTACH type="full"]4274[/ATTACH]
 

Attachments

  • 1629630842643.png
    1629630842643.png
    51.6 KB · Views: 4

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Gluetun works fine. I'm using it both for several other containers, and for proxying my browser through my...
Replies
3
Views
430
Thanks... I tried something similar with rsync. The docker volume lived in...
Replies
7
Views
619
I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
501
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
1,103
  • Question
Open an issue on that GitHub page. The developers will be glad to assist. OP has posted two threads on...
Replies
5
Views
1,093
I'm happy with email notifications but in v0.3.3 of dockcheck the author added apprise notifications...
Replies
4
Views
1,231
I am also trying to setup a Z-wave USB dongle and am getting stuck after following the same steps as...
Replies
1
Views
1,143

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top