Implement managing user/group permission with unison

[gagarine]

When I'm using rsync I can fix the permission to www-data but not with unison. Is their a workaround?

I want to use unison to have a two way sync. So for example I can see and edit the drupal config files generated by php.

[EugenMayer]

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.

[EugenMayer]

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 :)

[gagarine]

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).

[mickaelperrin]

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.

[EugenMayer]

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?

[mickaelperrin]

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

[EugenMayer]

@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?

[mickaelperrin]

Yes exactly.

[gagarine]

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.

[mickaelperrin]

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.

[EugenMayer]

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

[mickaelperrin]

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

[EugenMayer]

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