So, it turns out I’m implementing syncing of ownership. This will be implemented similarly to the xattr proposal I posted a while back, and is in fact a pre-requisite for that work. I’m aware that it’s a rabbit hole and many people will want different things, but I’m scoping it fairly tightly to begin with:
Syncing file ownership and group for POSIX systems
Syncing file ownership for Windows systems
Based on name or ID in priority, that is, if a file is owned by jb/501 on device A and there exists a user jb/1000 on device B, the ownership will sync jb → jb. If doesn’t exist on the destination the ownership will be UID 501 (as on the source).
Of course Windows is a bit different (names can include domains, the ID is a SID, etc.), but the APIs are there and it makes sense. What strikes me though when looking at it, is is it useful?
I mean, on Unixes the ownership and group are central to the file permissions. On Windows that’s not really the case, as far as I understand the only thing a file owner is good for is the ability to set ACLs under all circumstances.
So given that we still don’t sync Windows ACLs (or, until we do), is there really any driver or use case that requires syncing owners on Windows at all? Does anyone want this?
(Note that this is different from mapping, i.e. syncing KASTELO\Jakob Borg on some system to jb on another, which I’m not looking at for the moment.)
So far Syncthing doesn’t mess with the ownership on neither platform. It would be great if that behavior could still be configured in future Syncthing versions because to me it seems that syncing ownership does more harm than good regardless of the platform. At least I can only think of use cases where it would do harm.
Normally I just set it up so everything Syncthing will ever try to sync is owned by the user I start Syncthing with (or at least the group is matching and has full permissions). That user might be called differently on different ends (and the underlying IDs will surely differ on different ends) and I rely on Syncthing not caring about that.
For instance, on Windows I use a different user name than on my GNU/Linux systems (at least the casing usually differs) but both user names represent the same actual user.
If I want to sync folders under different ownership on the same machine I start a distinct Syncthing process for each user. However, on other nodes in the same cluster, e.g. an always-on sever, I wouldn’t care about these details from another machine’s user setup. The server should just store the data using the user I run Syncthing with.
If I sync a folder with a friend’s machine I really don’t want to care how his local user is called (and vice versa).
I’d like to note that the same NTFS file system might be accessed by e.g. GNU/Linux and Windows with a meaningful mapping of the users. That’s at least what I’m doing and I suppose many other users that have both operating systems installed on the same machine (or plug an external device on different machines). So a change done to the NTFS file system on Windows might have further effects when the file system is later accessed on GNU/Linux. However, I personally wouldn’t know a case when I’d like Syncthing to modify the ownership on Windows (and have that also affecting the access on GNU/Linux) for the general reasons stated before.
I’m also wondering how syncing the ownership would actually work in practice. Normally the user I start Syncthing with has no rights to change the ownership anyways. I suppose one would need to start Syncthing as root but I don’t think that’s generally a good idea.
User1 exists on computer2 (computer2\User1 - this is a different user from the user on Computer1, despite the same name, because they have different SIDs)
file1 on computer1 owned by computer1\User1 syncs to computer2
after sync, file1 on computer2 is owned by computer2\User1 (because Syncthing resolves the account name and they match)
I see this being of limited use because the original file owner is lost (computer1\User1 and computer2\User1 really are different accounts).
I would think this would be useful in a domain, though, where the SID of an account owner is valid across different hosts (if it’s domain rather than a local account).
Never fear, we’ve never introduced something like this as a mandatory (or maybe even default) thing as far as I know, and won’t do so now either. Especially since it requires elevated capabilities to even work (CAP_CHOWN on Linux).
If you enable owner sync in that scenario, yes. The priority order I did for Windows at this point is to use the same DOMAIN\user if it exists, otherwise just user under whatever the default domain is, otherwise copy the SID verbatim.
Indeed. The code is in fact already written, just not tested for Windows. The main downside of supporting Windows is that some extra layers of platform-independentness become required (build tags; UIDs being strings instead of integers). That is, it would be cleaner without Windows, but it’s fine with too. I mostly want to make sure I’m not doing something that any Windows user would look at and say “wtf why”.
For syncing ownership in general? Same as for syncing contents really, I guess, making one side the same as the other – but for multiuser systems, like mirroring a pair of NASes.
If you enable owner sync in that scenario, yes. The priority order I did for Windows at this point is to use the same DOMAIN\user if it exists, otherwise just user under whatever the default domain is, otherwise copy the SID verbatim.
I’m not sure I understand the last step (“otherwise copy the SID verbatim”). If the SID belongs to an authority that’s not resolvable in the current context (such as to a local account on a different computer, which would be the most likely scenario), then I don’t see the value of the last step (now I have files owned by a SID I can’t resolve, and I would have to change the owner to something useful).
Has this feature been implemented? I’m messing around with the potential of using SyncThing to sync files between remote data caches and a central store. I would like Windows ACLs to be replicated. Even though I plan on using Linux servers, the clients are Windows based and on a domain.
Nice work on this! SyncThing has impressed me since I started using it - this is the first area where I have a desire that doesn’t seem to be met.
The main downside of supporting Windows is that some extra layers of platform-independentness become required (build tags; UIDs being strings instead of integers). That is, it would be cleaner without Windows, but it’s fine with too. I mostly want to make sure I’m not doing something that any Windows user would look at and say “wtf why”.