When userSetup.sh Permission Setting takes too long the Container will infinitely restart

[theAkito]

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

Is there any comment in the documentation for this?

• I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

• I am using the latest release

Have you tried using the dev branch latest?

• I have tried using dev branch

Docker run config used

Undisclosed

Current Behavior

When setting the permissions here

docker-transmission-openvpn/transmission/userSetup.sh

Lines 49 to 72 in f9cb4de

	if [ "$GLOBAL_APPLY_PERMISSIONS" = true ] ; then
	echo "Setting owner for transmission paths to ${PUID}:${PGID}"
	chown -R ${RUN_AS}:${RUN_AS} \
	"${TRANSMISSION_DOWNLOAD_DIR}" \
	"${TRANSMISSION_INCOMPLETE_DIR}" \
	"${TRANSMISSION_WATCH_DIR}"
	echo "Setting permissions for download and incomplete directories"
	TRANSMISSION_UMASK_OCTAL=$(printf '%03g' $(printf '%o\n' $(jq .umask ${TRANSMISSION_HOME}/settings.json)))
	DIR_PERMS=$(printf '%o\n' $((0777 & ~TRANSMISSION_UMASK_OCTAL)))
	FILE_PERMS=$(printf '%o\n' $((0666 & ~TRANSMISSION_UMASK_OCTAL)))
	echo "Mask: ${TRANSMISSION_UMASK_OCTAL}"
	echo "Directories: ${DIR_PERMS}"
	echo "Files: ${FILE_PERMS}"
	find "${TRANSMISSION_DOWNLOAD_DIR}" "${TRANSMISSION_INCOMPLETE_DIR}" -type d \
	-exec chmod $(printf '%o\n' $((0777 & ~TRANSMISSION_UMASK_OCTAL))) {} +
	find "${TRANSMISSION_DOWNLOAD_DIR}" "${TRANSMISSION_INCOMPLETE_DIR}" -type f \
	-exec chmod $(printf '%o\n' $((0666 & ~TRANSMISSION_UMASK_OCTAL))) {} +
	echo "Setting permission for watch directory (775) and its files (664)"
	chmod -R o=rX,ug=rwX \
	"${TRANSMISSION_WATCH_DIR}"
	fi

takes longer, than 120 seconds, then OpenVPN will get a ping-restart after the permission job finished & the container will restart.

Expected Behavior

No OpenVPN issue should happen, when setting permissions takes longer than 120 seconds.

Or at least provide a useful error message. The current messages are extremely cryptic & basically don't say anything about what actually is not working.

How have you tried to solve the problem?

Workaround

Set GLOBAL_APPLY_PERMISSIONS=false as an environment variable to the container. It will skip setting the permissions.

Log output

[Secure-Server] Peer Connection Initiated with .....
...
...
...
Initialization Sequence Completed
...
...
...
resolv.conf was restored
Sending kill signal to transmission-daemon
/etc/transmission/stop.sh: line 16: kill: `': not a pid or valid job spec
Successfuly closed transmission-daemon
...
...
...
SIGTERM[hard,] received, process exiting

HW/SW Environment

Not related

Anything else?

I am currently using the workaround provided. It's good enough for now. However, it would be great, to fix the issue, or at least provide a useful error message in the logs. The current error messages are extremely generic & do not help at all in debugging the issue.

[pkishino]

Any reason why this would take so long? I can’t replicate this, it occurs instantaneous nearly in my setup

[theAkito]

A slow drive, which is slowed down additionally by a copy-on-write filesystem, which takes too many hardware resources, compared to the hardware provided.

I debugged this by opening a clean container, slowly applying all my settings step by step.
Once all my settings provided via environment variables worked inside that container, I guessed the only difference was how speedy the permission settings went.

If you want to replicate it, just mount an SSHFS file system to a remote target with lots of small files in it. For example, extract an Ubuntu DVD onto the remote folder, which is mounted locally & then use this as the data folder for this repository's stack.

[ncksnydr]

I have also experienced issues similar to this, but did not report because I am sub–one year into Docker and presumed user error. I am using Docker Swarm across nine single-board computers, but have one of those nine nodes dedicated to this container. The web UI freaks out with each automatic refresh if I run the image across multiple nodes in the swarm.

The application files are running on the node's SD card and download folder is an NFS drive on the same internal network. I've found that the haugene/transmission-openvpn:4.0 works with my setup, as it's the last tagged version before the /config and /storage paths were split. I stumbled across this issue because now the 4.0 tag is starting to fail.

Below is my docker-compose.yml for the "stack worker". A lot of the language is coded, but happy to walk through what needs clarification if it means the bug gets solved. Since the 4.0 image is failing, I am going to attempt to deploy the latest image and will post the logs after I censor sensitive data.

version: "3.9"
services:
  transmission:
    image: haugene/transmission-openvpn:4.0
    container_name: pimilor-transmission
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    dns:
      - 8.8.8.8
      - 8.8.4.4
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
      DEBUG: "TRUE"
      LOCAL_NETWORK: ${NETWORK_RANGE}
      OPENVPN_PROVIDER: ${VPN_PROVIDER}
      OPENVPN_CONFIG: ${VPN_REGION}
      OPENVPN_USERNAME: ${VPN_USERNAME}
      OPENVPN_PASSWORD: ${VPN_PASSWORD}
      OPENVPN_OPTS: ${VPN_OPTIONS}
      WEBPROXY_ENABLED: "TRUE"
      WEBPROXY_PORT: ${PIMILOR_TRANSMISSION_PORT_PROXY}
      TRANSMISSION_WEB_UI: transmission-web-control
    logging:
      driver: json-file
      options:
        max-size: 10m
    ports:
      - ${PIMILOR_TRANSMISSION_PORT}:9091
      - 8888:8888
    restart: always
    security_opt:
      - seccomp:unconfined
    volumes:
      - cofbilion:/data
      - /etc/localtime:/etc/localtime:ro
    deploy:
      replicas: 1
      placement:
        constraints: [node.hostname == gadathli]

  proxy:
    image: haugene/transmission-openvpn-proxy:4.0
    container_name: pimilor-transmission-proxy
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
    links:
      - transmission
    ports:
      - ${PIMILOR_TRANSMISSION_PORT_PROXY}:8080
    volumes:
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - transmission
    deploy:
      replicas: 1
      placement:
        constraints: [node.hostname == gadathli]

  rss:
    image: haugene/transmission-rss:4.0
    container_name: pimilor-transmission-rss
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
      RSS_URL: http://${RAEDORVUDH_IP}:${PIMILOR_TRANSMISSION_PORT}/pimilor.rss
    links:
      - transmission
    volumes:
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - transmission
    deploy:
      replicas: 1
      placement:
        constraints: [node.hostname == gadathli]

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: pimilor-radarr
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
    ports:
      - ${PIMILOR_RADARR_PORT}:7878
    restart: unless-stopped
    volumes:
      - ${PIMILOR_RADARR_PATH}:/config
      - thinmbahad-movies:/movies
      - cofbilion-movies:/downloads
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - transmission
    deploy:
      replicas: 1
      placement:
        constraints: [node.labels.pimilor == true]

  sonarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: pimilor-sonarr
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
    ports:
      - ${PIMILOR_SONARR_PORT}:7878
    restart: unless-stopped
    volumes:
      - ${PIMILOR_SONARR_PATH}:/config
      - thinmbahad-tv:/tv
      - cofbilion-tv:/downloads
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - transmission
    deploy:
      replicas: 1
      placement:
        constraints: [node.labels.pimilor == true]


  ytdl_material:
    image: tzahi12345/youtubedl-material:latest
    container_name: pimilor-ytdl-app
    environment:
      ALLOW_CONFIG_MUTATIONS: "TRUE"
      write_ytdl_config: "TRUE"
      ytdl_allow_advanced_download: "TRUE"
      ytdl_allow_subscriptions: "TRUE"
      ytdl_allow_theme_change: "TRUE"
      ytdl_default_theme: "default"
      ytdl_download_only_mode: "TRUE"
      ytdl_include_metadata: "TRUE"
      ytdl_include_thumbnail: "TRUE"
      ytdl_max_concurrent_downloads: 3
      ytdl_mongodb_connection_string: 'mongodb://ytdl-mongo-db:27017'
      ytdl_multi_user_mode: "TRUE"
      ytdl_use_local_db: "TRUE"
      ytdl_use_youtubedl_archive: "TRUE"
    ports:
      - ${PIMILOR_YTDL_PORT}:17442
    restart: always
    volumes:
      - ${PIMILOR_YTDL_PATH}:/app/appdata
      - cofbilion-audio:/app/audio
      - cofbilion-video:/app/video
      - cofbilion-video:/app/subscriptions
      - cofbilion-video:/app/users
    depends_on:
      - ytdl-mongo-db
    deploy:
      replicas: 2
      placement:
        constraints: [node.labels.pimilor == true]

  ytdl-mongo-db:
    image: mongo:4.4.6
    container_name: pimilor-ytdl-db
    ports:
      - ${PIMILOR_YTDL_DB_PORT}:27017
    logging:
      driver: "none"
    restart: always
    volumes:
      - ${PIMILOR_YTDL_PATH}/database:/data/db
    deploy:
      replicas: 1
      placement:
        constraints: [node.labels.database == true]

volumes:
  cofbilion:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${COFBILION_PATH}
  cofbilion-audio:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${COFBILION_PATH}/public/audio
  cofbilion-movies:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${COFBILION_PATH}/public/movies
  cofbilion-tv:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${COFBILION_PATH}/public/tv
  cofbilion-video:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${COFBILION_PATH}/public/video
  thinmbahad-movies:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${THINMBAHAD_PATH}/media/movies
  thinmbahad-tv:
    driver: local
    driver_opts:
      type: nfs
      o: addr=${NFS_IP},${NFS_OPTIONS}
      device: :${THINMBAHAD_PATH}/media/tv

[ncksnydr]

For those of you dealing with a similar issue, I can expand upon the workaround discovered by @theAkito.

1. Add GLOBAL_APPLY_PERMISSIONS=false into your environment variables to start.
2. Start the container/stack. If the userSetup.sh script used to timeout, it shouldn't anymore and should start successfully.
3. The container/stack will not have the correct permissions to add/start torrent files. Comment out the GLOBAL_APPLY_PERMISSIONS=false environment variable and update the container/stack.

This fixed the issue for me, but your mileage may vary. Hope this helps someone else; big thanks for @theAkito for the initial report.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[theAkito]

Still relevant.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[abayomi185]

I just faced this same issue recently, the transmission UI won't come up and I was unable nslookup any domains in the container leading me to think it was a network or VPN issue, but I could ping the VPN IP. I then thought it could perhaps be the VPN DNS but changing this didn't fix things. The container infinitely restarted but I was able to resolve this issue with GLOBAL_APPLY_PERMISSIONS=false as mentioned.

I'm running an EXT4 FS on a healthy HDD over NFS and this had been working with no issues for over 2 years.

[colton-nicotera]

Would like to add that this is still an ongoing issue. Took me forever to debug as well because it's not apparent what is causing the timing out.

[theskillwithin]

how can I fix this in unraid?