Skip to content
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

Data file permissions #13

Closed
ab623 opened this issue May 17, 2015 · 16 comments
Closed

Data file permissions #13

ab623 opened this issue May 17, 2015 · 16 comments

Comments

@ab623
Copy link
Contributor

ab623 commented May 17, 2015

The newly created torrent directory will be stored on the host with a permission of 644 and as root:root.

Can this be configured to allow me to pass my user and group into the container, so that when writing the torrent, it will write correctly to my host file system, removing the need for my to use sudo to change the configuration.

I have a script which moves and sorts these files, and I don't want to elevate the scripts privileges, as this can be done in the container.

Thanks

@haugene
Copy link
Owner

haugene commented May 19, 2015

I agree, hopefully I'll get some time to look into that. Mapping it to your user on the host system would be a good option. If you have any thoughts on how, send a PR.

In the mean time, you could do what I've done. Using the group flag on the directory mounted as /data and its subdirectories. It will make sure that all files created in that folder has the same group as the parent folder. So you make a group "data-movers" and set it on the folder, and add your user to it and you shouldn't need sudo.

If files are created without write permissions for group, some defaults to 775 others to 755, you can set the umask 002 to make them group writable (775).

Let me know if it works!

More on the topic:
http://unix.stackexchange.com/questions/12842/make-all-new-files-in-a-directory-accessible-to-a-group

@ab623
Copy link
Contributor Author

ab623 commented May 20, 2015

How about you pass 3 env variables in: USER, GROUP, PERMISSION.

If aren't set they will default to root, root, 644.

If they are set then we do a groupadd, adduser, usermod -a -G grouptoadd username, and we run the container as that user. This would be the preferred approach.

OR

We run the container as root, we still create the user and group, but when the torrent finishs we get it to run a script which run the appropriate following commands. chmod, chown, chgrp.

@ab623
Copy link
Contributor Author

ab623 commented May 20, 2015

Could you provide some further information. Maybe on the wiki about how you achieved your setup using uname. Until a more permanent solution is found. Thanks.

@haugene
Copy link
Owner

haugene commented May 21, 2015

Turns out I did it with uname and g+s stuff before, while I now run post processing in another Docker container, so it's also root:root. Anyways, googling this I end up at this issue: moby/moby#7198

Maybe you can try what jjrv suggested, although it's supposed to have a performance hit. For post-processing torrents it might be ok though.

I hacked around this in Ubuntu outside Docker. Install package bindfs and bind the directory with volume contents to another path while mapping UID and GID to ones used inside the container:

sudo bindfs -u UID -g GID oldpath newpath

Then use newpath as a docker volume. Oldpath still shows ownership correct for the host, newpath for the guest.

@ab623
Copy link
Contributor Author

ab623 commented May 26, 2015

So I think the best way to work around this, without using multi-container is to pass in env variables for username and group, and then to add that user. Then using an inotify-wait or using transmissions script option. To chown & chmod the new files to the respective values. Without specifying these options the files will remain as root.

Does that sound like a decent option. I will try to code it up and write a PR.

@haugene
Copy link
Owner

haugene commented May 27, 2015

Sounds good! 👍 for a PR on this.

Could also try to run transmission as the wanted user, that might make it save files with the right permissions. I'm wondering how it is with mapping username and group from the container to the host. Maybe one need to pass the UID/GID to the container.

@ab623
Copy link
Contributor Author

ab623 commented May 27, 2015

I coded it last night. I pass in the username and group name along with the
userid and groupid. I really only need the userid and groupid and I can
dummy the user and group name. I might do it both ways. Passing in nothing
will default to root.

I just need to check that when transmission auto-completes it is running
the script properly

The reason why I didn't bother running the starting the daemon as the user
is because there's no way of passing in custom info into the docker file.

I will continue with this today. Hopefully get it done.

Anything else you think I should include and consider?

Sounds good! [image: 👍] for a PR on this.

Could also try to run transmission as the wanted user, that might make it
save files with the right permissions. I'm wondering how it is with mapping
username and group from the container to the host. Maybe one need to pass
the UID/GID to the container.


Reply to this email directly or view it on GitHub
#13 (comment)
.

@haugene
Copy link
Owner

haugene commented May 27, 2015

Cool, looking forward to see it! Sounds like you've got it covered. And as you wrote about the parameters, if uid/gid is all that is needed I guess less parameters is better. User and group name could be optional.

@ab623
Copy link
Contributor Author

ab623 commented Jun 1, 2015

Everything is working fine in terms of setting up users etc. However the main issue is the chown and chmod process. Im having a great deal of issues with transmission executing my script, and was wondering if you have any ideas.

The script that runs when a torrent finishes is like below:

 echo "Torrent finished"
 /bin/chown ....
 /bin/chmod ....

Now if I echo something, it should appear when I run a docker logs <container ID> but it doesn't. But if I change my script along the lines of

echo "Torrent finished" > /data/torrent.txt

then the file is created as expected. So you would expect the chown and chmod to run, but it doesn't at all. So the issue is, I'm not really sure why the script isn't acting as it should. Its not a permission issue, as everything is running as root.

Do you have any ideas/workarounds. I'll push the code onto my rep in a short while, and you can pull it down to have a look. The only other way I would think might be good would be to use inotifywait and wait until something is dropped in the completed folder, and run the command, but i like the idea of the script running on completion as it can be extended to do more things. Email the user, log down completion times, etc.

@tsromana
Copy link
Contributor

i used TRANSMISSION_UMASK= variable to deal with permissions works good. use value 0 to give file 777 permission and the sorting script can change file permission to whatever you like after moving it.

@ab623
Copy link
Contributor Author

ab623 commented Aug 20, 2015

Can you post an example of your full docker command then. I think I tried this, but I must not have done it right.

@tsromana
Copy link
Contributor

@amishb

docker run --privileged -d
-v /home/unsorted/:/data
-e "OPENVPN_PROVIDER=PIA"
-e "OPENVPN_CONFIG=xxxx"
-e "OPENVPN_USERNAME=xxxx"
-e "OPENVPN_PASSWORD=xxxx"
-e "TRANSMISSION_UMASK=0"
-p 9091:9091
--name transmission
haugene/transmission-openvpn

try this you can add any other variable to it if you want any help i am here to answer

@ab623
Copy link
Contributor Author

ab623 commented Aug 28, 2015

@tsromana

So I added the UMASK=0 setting into my config, and the torrent is fine, and its setting my permissions correctly.

drwxrwxrwx 2 root  root   4.0K Aug 28 16:56 3 Idiots 2009 720p BluRay x264 Hindi AAC - Ozlem/

but i still get an error when doing a chmod

admin@snow:/mounts/media/incoming$ chmod -R 775 automatic/ & ll automatic/
[1] 4967
chmod: changing permissions of ‘automatic/3 Idiots 2009 720p BluRay x264 Hindi AAC - Ozlem’: Operation not permitted
chmod: changing permissions of ‘automatic/3 Idiots 2009 720p BluRay x264 Hindi AAC - Ozlem/3 Idiots 2009 720p BluRay x264 Hindi AAC - Ozlem.mp4’: Operation not permitted
chmod: changing permissions of ‘automatic/3 Idiots 2009 720p BluRay x264 Hindi AAC - Ozlem/Ozlem.png’: Operation not permitted
total 1.4G

This is because transmission is creating the file as root:root in the container, which is then also created as root:root on my actually filesystem, which means my normal user cant change anything, because I'm not running as root.

Any ideas/suggestions?

@haugene
Copy link
Owner

haugene commented Sep 26, 2015

I think I'll close this issue soon as it isn't so much an issue with this Docker container but more Docker itself and how we use it.

You're right that regular users cant chmod files that are owned by root. But you should be able to move them around and even delete them. I would just let root be the owner and do you post processing without changing that. Then you could run a chown -R on your data folders once in a while.

Another alternative is to not mount the /data volume to your host. Instead have a post processing script in Transmission that use scp or sftp to send the file to your host. Then the files will be owned by the account used for scp/sftp. A little extra setup and you would duplicate the files while seeding, and that would take up disk space.

Or have you found another solution since your last post?

@tsromana
Copy link
Contributor

@haugene did you try umask option because it works really good for me

@haugene
Copy link
Owner

haugene commented Sep 28, 2015

I don't use it, I have a different setup. But I agree that the umask option should work, setting it to 0 will allow non-root users to move and rename files. It will however not allow them to run chmod/chown.

@amishb is trying to do chmod on the files and that will not work because they're still owned by root. That's why I suggest he use the umask solution, let post processing rename/move files and then do bulk permission changes later.

@haugene haugene closed this as completed Oct 5, 2015
steveneighbour pushed a commit to steveneighbour/openvpn that referenced this issue Apr 17, 2021
*Added some missing ProtonVPN P2P servers (CH haugene#5-13, SG haugene#13-20)
*Updated (and removed non-P2P ) AreaVPN servers as per issue haugene#775
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants