Init fails on chown for NFS directories

leukanos commented 1 year ago

Expected Behavior

Transmission should work correctly with mounted NFS folder. (it was working correctly for version linuxserver/transmission:3.00-r5-ls138)

Current Behavior

init-transmission-config fails on chown for complete and incomplete folders:

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/

Brought to you by linuxserver.io
-------------------------------------

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    1000
User gid:    1000
-------------------------------------

chown: changing ownership of '/downloads/complete': Operation not permitted
chown: changing ownership of '/downloads/incomplete': Operation not permitted
s6-rc: warning: unable to start service init-transmission-config: command exited 1

Steps to Reproduce

Use the mounted NFS download folder (or mounted complete/incomplete folders inside download) as download volume
Run docker-compose

Environment

OS: Ubuntu 22.04 LXC on Proxmox CPU architecture: x86_64 How docker service was installed:

Command used to create docker container (run/create/compose/screenshot)

version: "2.1"
services:
  transmission:
    image: lscr.io/linuxserver/transmission:latest
    container_name: transmission
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - TRANSMISSION_WEB_HOME=/combustion-release/ #optional
      - USER=leukanos #optional
      - PASS=pinky-winky #optional
    volumes:
      - /home/docker/arr/transmission/data:/config
      - /home/docker/downloads:/downloads
      - /home/docker/arr/transmission/watch:/watch
    ports:
      - 9091:9091
      - 51413:51413
      - 51413:51413/udp
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

Docker logs

github-actions[bot] commented 1 year ago

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

Lexxior commented 1 year ago

I can confirm, same config and same issue Reverting to the previous version fixed the error

Roxedus commented 1 year ago

Give lspipepr/transmission:3.00-r6-pkg-2861d237-pr-215 a try

gotson commented 1 year ago

Give lspipepr/transmission:3.00-r6-pkg-2861d237-pr-215 a try

I still have the same issue with your image above:

[custom-init] No custom services found, skipping...
[migrations] started
[migrations] no migrations found

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/

Brought to you by linuxserver.io
-------------------------------------

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    1000
User gid:    1000
-------------------------------------

chown: changing ownership of '/downloads': Operation not permitted
chown: changing ownership of '/downloads/complete': Operation not permitted
chown: changing ownership of '/downloads/incomplete': Operation not permitted
chown: changing ownership of '/watch': Operation not permitted
s6-rc: warning: unable to start service init-transmission-config: command exited 1

leukanos commented 1 year ago

I can confirm it's working for the latest version. Thanks for the fix!

gotson commented 1 year ago

I can confirm it's working for the latest version. Thanks for the fix!

i'm still having issues on latest :(

vivami commented 1 year ago

I can confirm it's working for the latest version. Thanks for the fix!

i'm still having issues on latest :(

Same here, I'm also still having the same issue on latest. Downgrading to 3.00-r5-ls138 fixes the issue.

thespad commented 1 year ago

I'm going to assume you're doing some kind of permission squashing that means the remote volume reports the wrong permissions to the container, so it thinks it needs chowning.

There's a limit to what we can do here, we don't want to have the container init when it can't set up the environment properly for it to work OOTB for most users, and we can't possibly detect every possible weird setup and know that it's OK. The simplest solution is just don't use /downloads and /watch as your paths - they are the only directories we touch on init (apart from /config).

gotson commented 1 year ago

I don't do anything specific, I have a mount which is from a synology nas which has ACLs. There's nothing fancy in that.

What would make sense would be either to:

not try to jack up the permissions automatically
or provide a config to prevent that
or if chown fails, still start the container

I don't quite understand why you need to own the folders. What's the point of doing that? The container only needs to be able to write, you don't need to own the folder for that.

Case in point, it worked fine before.

vivami commented 1 year ago

@thespad That's correct, I export the NFS shares on the host (proxmox) using all_squash,anonuid=65534,anongid=65534,rw,sync,no_subtree_check,crossmnt, because I don't really care about the permissions/security of these files, and it's over complicating things across VM's and containers.

I agree with @gotson, I don't understand the change(s) made in 3.00-r6-ls139 that prevent init-transmission-config from starting.

On 3.00-r5-ls138 the chown operations also fail, but transmission starts regardless (as it always used to do in previous versions):

transmission    | [custom-init] No custom services found, skipping...
transmission    | s6-rc: info: service s6rc-oneshot-runner: starting
transmission    | s6-rc: info: service s6rc-oneshot-runner successfully started
transmission    | s6-rc: info: service fix-attrs: starting
transmission    | s6-rc: info: service 00-legacy: starting
transmission    | s6-rc: info: service 00-legacy successfully started
transmission    | s6-rc: info: service fix-attrs successfully started
transmission    | s6-rc: info: service legacy-cont-init: starting
transmission    | cont-init: info: running /etc/cont-init.d/01-envfile
transmission    | [env-init] PASS set from FILE__PASS
transmission    | cont-init: info: /etc/cont-init.d/01-envfile exited 0
transmission    | cont-init: info: running /etc/cont-init.d/01-migrations
transmission    | [migrations] started
transmission    | [migrations] no migrations found
transmission    | cont-init: info: /etc/cont-init.d/01-migrations exited 0
transmission    | cont-init: info: running /etc/cont-init.d/10-adduser
transmission    |
transmission    | -------------------------------------
transmission    |           _         ()
transmission    |          | |  ___   _    __
transmission    |          | | / __| | |  /  \
transmission    |          | | \__ \ | | | () |
transmission    |          |_| |___/ |_|  \__/
transmission    |
transmission    |
transmission    | Brought to you by linuxserver.io
transmission    | -------------------------------------
transmission    |
transmission    | To support LSIO projects visit:
transmission    | https://www.linuxserver.io/donate/
transmission    | -------------------------------------
transmission    | GID/UID
transmission    | -------------------------------------
transmission    |
transmission    | User uid:    1000
transmission    | User gid:    1000
transmission    | -------------------------------------
transmission    |
transmission    | cont-init: info: /etc/cont-init.d/10-adduser exited 0
transmission    | cont-init: info: running /etc/cont-init.d/20-config
transmission    | chown: changing ownership of '/downloads': Operation not permitted
transmission    | chown: changing ownership of '/downloads/complete': Operation not permitted
transmission    | chown: changing ownership of '/downloads/incomplete': Operation not permitted
transmission    | chown: changing ownership of '/watch': Operation not permitted
transmission    | cont-init: info: /etc/cont-init.d/20-config exited 1
transmission    | cont-init: info: running /etc/cont-init.d/99-custom-files
transmission    | [custom-init] No custom files found, skipping...
transmission    | cont-init: info: /etc/cont-init.d/99-custom-files exited 0
transmission    | s6-rc: info: service legacy-cont-init successfully started
transmission    | s6-rc: info: service init-mods: starting
transmission    | s6-rc: info: service init-mods successfully started
transmission    | s6-rc: info: service init-mods-package-install: starting
transmission    | s6-rc: info: service init-mods-package-install successfully started
transmission    | s6-rc: info: service init-mods-end: starting
transmission    | s6-rc: info: service init-mods-end successfully started
transmission    | s6-rc: info: service init-services: starting
transmission    | s6-rc: info: service init-services successfully started
transmission    | s6-rc: info: service legacy-services: starting
transmission    | services-up: info: copying legacy longrun cron (no readiness notification)
transmission    | services-up: info: copying legacy longrun transmission (no readiness notification)
transmission    | s6-rc: info: service legacy-services successfully started
transmission    | s6-rc: info: service 99-ci-service-check: starting
transmission    | [ls.io-init] done.
transmission    | s6-rc: info: service 99-ci-service-check successfully started

aptalca commented 1 year ago

To be honest, your use case represents a very tiny percentage of our user base. And by that I don't mean nfs users because I also use nfs, but because I set it up properly, I don't experience the issue you're facing.

So if you have any constructive feedback, or any ideas that can fix your issue while not negatively impacting the other users' experience, we're all ears.

gotson commented 1 year ago

To be honest, your use case represents a very tiny percentage of our user base. And by that I don't mean nfs users because I also use nfs, but because I set it up properly, I don't experience the issue you're facing.

So if you have any constructive feedback, or any ideas that can fix your issue while not negatively impacting the other users' experience, we're all ears.

An environment variable to keep the previous behaviour.

vivami commented 1 year ago

To be honest, your use case represents a very tiny percentage of our user base. And by that I don't mean nfs users because I also use nfs, but because I set it up properly, I don't experience the issue you're facing.

So if you have any constructive feedback, or any ideas that can fix your issue while not negatively impacting the other users' experience, we're all ears.

I understand that you don't want to make exceptions for "a tiny percentage" of your user base. I was just wondering why the change was made, and what the requirement of the chowns are (i.e. are they really necessary).

Regardless, I'll use the solution suggested by @thespad going forward, when I decide to update to > 3.00-r5-ls138.

If know a good guide on how to "properly set up" NFS, please share. Thanks

aptalca commented 1 year ago

It's not that we don't want to make exceptions, it's a matter of maintaining a balance between increased workload and not wanting to impact other users.

Implementing additional measures increases our workload and we already have a huge backlog of bug fixes and improvements.

Chown is necessary and crucial for the majority of our users. Removing it breaks it for many so it's not acceptable as a solution.

The change is not something we did specifically. It's due to a behavior change in the supervisor we use, which got updated from v2 to v3 (lots of changes, pretty much a rewrite). Not something that can be reverted with an env variable.

gotson commented 1 year ago

Not something that can be reverted with an env variable.

Wouldn't it be possible to not perform the chown if a specific environment variable is present, similar as what's been done in https://github.com/linuxserver/docker-transmission/pull/215/files ?

anroots commented 1 year ago

I'm one of the tiny percentage of users (by running the image on K8s with NFS PersistentVolume-s). I've worked around the issue by:

creating a ConfigMap containing the original init script WITHOUT the chown lines
mounting it into the container thereby overwriting the config script (with execute permission defined on the file)
running the pod that way

NFS share and files there mount with correct permissions.

Note also commit https://github.com/linuxserver/docker-mods/pull/521/files

gotson commented 1 year ago

Not something that can be reverted with an env variable.

Wouldn't it be possible to not perform the chown if a specific environment variable is present, similar as what's been done in https://github.com/linuxserver/docker-transmission/pull/215/files ?

@aptalca any thoughts on this?

teppot commented 11 months ago

Still happens on latest with completely standard NFS mounts and correct permissions. I don't understand how to implement the workarounds suggested here.

aptalca commented 11 months ago

Please open a new issue. Many changes have been made since this one

linuxserver / docker-transmission