New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using NFS share for "/downloads" crashes the container #487
Comments
There's not a way to change 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 |
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? |
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 The |
I tried mounting a NFS share as "/downloads" and Docker threw an error, saying "Error response from daemon: failed to copy file info for /var/lib/docker/volumes//_data: failed to chown /var/lib/docker/volumes//_data: lchown /var/lib/docker/volumes//_data: operation not permitted"
I also set the environment variable for not resetting the download directory permissions, and that didn't fix the issue.
Is there a way to change "/downloads" to a different path once the container is running?
The text was updated successfully, but these errors were encountered: