Implement managing user/group permission with unison about docker-sync HOT 13 CLOSED

I am very open minded here, but for know, this feature has to rely on contributions out from the community. I hope some people will have better/good ideas on this issue, as far as i know, it has yet not been tackled by any alternatives yet.

So please, get involved or ask people to get involved on this issue :)

from docker-sync.

For unison, there is yet none, there is work undergo though #21 i think unison itself in its way of 2 way syncing will make it hard to cope with this mappings - i am not actively working on this though.

If you want to use 2way sync with unison, your best bet is chaning your dev-image to run on specific uids matching your OSX probably - i yet do not know.

I keep this issue open as a feature.

from docker-sync.

I did some test and read the union doc.

From the union doc https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html

perms n
The integer value of this preference is a mask indicating which permission bits should be synchronized. It is set by default to 0o1777: all bits but the set-uid and set-gid bits are synchronised (synchronizing theses latter bits can be a security hazard). If you want to synchronize all bits, you can set the value of this preference to −1. If one of the replica is on a FAT [Windows] filesystem, you should consider using the t fat preference instead of this preference. If you need Unison not to set permissions at all, set the value of this preference to 0 and set the preference t dontchmod to t true.

It's what I observe, changing user or group have no effect but permissions are synchronized.

More doc:

When the times preference is set to true, file modification times are propaged. (Because the representations of time may not have the same granularity on both replicas, Unison may not always be able to make the modtimes precisely equal, but it will get them as close as the operating systems involved allow.)

• When the owner preference is set to true, file ownership information is synchronized.
• When the group preference is set to true, group information is synchronized.
• When the numericIds preference is set to true, owner and group information is synchronized numerically. By default, owner and group numbers are converted to names on each replica and these names are synchronized. (The special user id 0 and the special group 0 are never mapped via user/group names even if this preference is not set.)

So the way to "force" a user and group is to run unison has another user.

It's also possible to sync owner and group (by name or numerically).

from docker-sync.

The idea behind the PR linked an the new one #47 is to make unison sync the userid numerically.

Say that you run docker-sync with the user 501.

In the volume container, files would belong to the user 501 without any real name.

In the app container where you use the volume, you have to create an init script that change the uid of the user who needs permissions to write in the voume. Example for fpm running with www-data:

usermod -u 501 www-data

To make your script portable, you can use the fact that the unison volume change the owner of the mounted folder to the appropriate id, so you could do something like:

usermod -u $(stat -c '%u' /src) www-data

where /src is the path of the mounted volume in the app container.

from docker-sync.

Is there any reason you pick a static 501? is this because of your OSX uid? couldnt we pick the uid, the app container potentially has, so the setting what is needed in docker-sync.yml?

from docker-sync.

This is an example. The way to get the appropriate uid is to use the stat version.

from docker-sync.

@mickaelperrin so people have to get there uid on the host ( OSX ) and then reconfigure there target app-container to use this uid, right? Obviously doing the opposite as in rsync does not work due to the "sync back" from sync container to osX?

from docker-sync.

Yes exactly.

from docker-sync.

Why not matching the user/group name? I think it would be easier for users. You just need to create a user with the same name on both machine. Or perhaps expose those options in the settings so people can chose?

On my use case I just need to force a user.

from docker-sync.

This allows you to use the same volume in multiple containers that runs differents users. But, for simpler use cases, running unison in a different user than root could work also.

from docker-sync.

@mickaelperrin thats more or less solved, isnt it? We have user mapping for now, thats enough for basically all cases, isn't it?

from docker-sync.

Indeed, we manage user with the latest release but not group. Sufficient for development purposes.

from docker-sync.

great, since both is implemented in rsync, we can close this issue. Thanks for the feedback!

from docker-sync.