Using NFS share for "/downloads" crashes the container about tubesync HOT 3 OPEN

There's not a way to change /downloads, but you can map it to any directory on the host using volumes so that shouldn't be an issue.

Your specific problem is caused by NFS permissions issues. You can fix this with UID mapping, root squashing or any of the usual NFS permission hacks. Or, set the PUID and GUID vars to whatever user has permission to access the NFS share. Also your volume paths look weird, I'd suggest you try using a directory for the volume on the share and not a Docker volume.

from tubesync.

I think the volume directory looks weird because I used angle brackets to take out some personal items and put text that was something like "container name" those disappeared entirely...

On the NFS issue, it's already set to map all users to the owner on the NAS (and, I actually tried it with the admin account for the NAS, to ensure there wasn't any subtle permissions issue going on... and it still failed). I think the issue could be that chown needs an admin or elevated permissions in Docker, but I don't see why the container would need to run "chown" on an existing directory structure--especially with me having set the "Reset Download Folder" option to FALSE? And this was the error thrown by Docker Compose, so it is something that happens when creating the container, so I'm doubly confused why just pulling the image and setting up the container would trigger this unless the ownership changes are part of the initial container setup?

from tubesync.

The only chown executed at all is in the container start-up in a shell script here:

https://github.com/meeb/tubesync/blob/main/config/root/etc/s6-overlay/s6-rc.d/tubesync-init/run

The only volume this is run on (if TUBESYNC_RESET_DOWNLOAD_DIR is set to False) is /config so I can only assume /config is on your NFS volume as well? /config won't work on an NFS share as it's primarily used for the SQLite database.

The chown is primarily because people were doing things like copying in the SQLite database into the /config dir on the host and it was owned by their local user not the container runtime user and there were lots of reports of weird SQLite access and permissions errors for a while. chown-ing the config directory to the user the container runs as seemed reasonable rather than having people have to sudo chown 10000 ... etc. on the host machine.

from tubesync.