Is it possible to use the SyncOwnership functionality with macOS, either when running syncthing via a user login or via a launchd plist?
There is no mention of macOS in the documentation for this section, saying it works, or saying that it doesn’t.
And if it can be made to work, can anyone let me know what is required in both cases?
Thanks, Sean
macOS is mostly Unix-like under the hood, so the Unix implementation section is accurate.
Generally speaking, when running Syncthing under a regular user, for security reasons it won’t be able to sync ownership of files/directories to arbitrary users. You’ll have to sort out how to run Syncthing with elevated privileges.
I am pretty sure that setcap is a very specific Linux (not even generic Unix) command that doesn’t exist under macOS, so do you ignore that command, or is there another way to accomplish the same thing?
Could you provide some details as to what the goal is?
Gadget,
I have two macOS computers, each with a large external drive full of photos and some other media I’d like to sync one way (sender—>receiver). When I have sent/set permissions and extended attributes turned on the receiving disk (which already has a slightly older version of the files), it stays stuck in “Preparing Sync” forever. There was no hint as to why this was in the standard logs (which seemed odd to me), but when I turned on all the debugging logs on the receiver, I noticed that there were chown related error.
Since I had been troubleshooting this for days on end, I decided to disable both the permissions and attributes sync to see if that made a difference. And indeed, it did.
Things are much better, but not perfect.
I am pretty technical, but the documentation and logs are not as helpful as they could be, so troubleshooting further has been tricky.
I would prefer to have as close to a perfect backup/copy as I can. I haven’t taken a look at the code to see how it is using chown. Like, does the named user need to exist, or just the UID/GID that was on the original system?
Anyhow, my goal is to get as close to an identical copy on the second MacOS system as I can so that I can keep that as a reasonably up-to-date backup in another room in the house.
Tips, tricks, and/or recommendations?
Having written a lot of documentation for work, it’s never easy balancing the needs of both technical and non-technical users. More detailed documentation often turns off non-technical users who much prefer a quick fix (a reason why ChatGPT and other chatbots are turning into popular search engines).
Enabling all of the debugging info by default adds system load and is generally only of interest when there’s an issue.
I can’t do better than what’s already written, so quoting from the Unix implementation section:
Syncthing records both the numerical UID and GID for a file and the corresponding user and group names, when they are known. When applying ownership Syncthing will first attempt to look up a local user or group with the given name, and if that fails it will fall back to the numerical UID and GID.
On a related note, UID and GID aren’t guaranteed to be the same, so restoring files to a different system – or one that’s been rebuilt after a drive failure or other major issue – can be unreliable (restored files could end up being owned by the wrong user/group).
Since you’ve been trying to sync ownership, and NTFS doesn’t support the POSIX UID/GID, I’m assuming that your external drives are formatted as APFS volumes. Unless the specs for APFS have changed since I last checked, APFS doesn’t checksum user data so bitrot can go undetected.
If the filesystem or files on the external drive on the sending Mac get corrupted, unless it results in an OS-level error that gets passed onto Syncthing, the corruption will be synced to the external drive on the receiving Mac before it’s likely to be noticed.
So although Syncthing is a fine companion to a proper backup tool, it’s not a replacement for one. The receiving Mac in the other room needs to be separately backing up the files somewhere other than the existing external drive (e.g. another drive, cloud storage).
I previously posted about backup tools in an earlier thread: https://forum.syncthing.net/t/syncing-to-cloud-blackup/21219
Circling back to your earlier question…
Right, other OSes have some variation of capabilities but macOS doesn’t have a setcap command.
First option that comes to mind is setuid and setgid. There are serious security considerations to enabling either one, so best to consider the caveats before diving in:
Elevating Privileges Safely – https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html
Another option is dependent on how Syncthing on your sending Mac is currently able to access all of the files on the external drive. If all of the files are owned by a single user, but that user doesn’t exist on the receiving Mac, then adding that user and having it run Syncthing would solve the permissions issue.
Along the same lines, if there are multiple users with files on the external drive, running separate Syncthing instances (one for each user) on both Macs is another option. Each Syncthing instance would then have the necessary permissions to read/write the files it’s syncing.
Sure. I understand that, but I’d argue that the documentation would be more helpful if an entry like Syncthing Configuration — Syncthing documentation provided more information (even a link to somewhere else in the docs) beyond basically restating the name of the config option. I’m sure it is obvious to the developers, but I bet that many new users end up on that page via their own research or due to recommendations from the forums, and the descriptions don’t often really make it clear what it impacts, or why someone might adjust it.
Obviously, enabling all the logs by default is not a good idea, but real errors should be bubbled up in general. The fact that you can get a lot of “hard” errors that completely break syncing and see NOTHING in the logs, is pretty painful for all users, but especially those who aren’t pretty technical already.
Actually, I think that this is the issue, and maybe an interesting edge case. So, in my case, I have 2 computers, each with a user with the same UID and running Syncthing. However, the second (receiver) computer has a different UID (uer) with the same username as the first (sender) system. Since, Syncthing tries to change the UID to the username first, this is likely where the error is coming from.
The drives are indeed APFS, but I am not using Syncthing as a primary backup mechanism. However, I would still prefer that the permissions and extra attributes be synced, which is what I was originally writing about.
This comes back to my comment about the documentation. The documentation does not list this as a Linux option, it lists it as the “Unix implementation”, and generally appears to lump macOS under there. I understand that there are other ways to do this, but it is an area where the documentation could be improved, and I can certainly PR an improvement, but I would need to understand the details, so that is where it all gets a bit more tricky without being able to get some feedback from active developers/contributors.
Issue created: Improve the Folder Sync Ownership documentation · Issue #9560 · syncthing/syncthing · GitHub
Thanks for this. I was mostly wondering if there was a way that this was intended to work with Syncthing, but since I am pretty sure that the underlying issue in my case, is that although I have the same UID running Syncthing on both machines, the fact that the username from the first machine actually machines a different UID on the second machine, this causes the failure, since SyncThing tries to use the username first, and there isn’t an obvious way to change this behavior at the moment.
I created an issue here: Make it possible to prefer UID/GID over usernames when syncing permissions · Issue #9559 · syncthing/syncthing · GitHub
Even if Syncthing offered the option of trying the UID/GID first before user/group, there would still be the original issue of how to grant Syncthing the necessary privileges to set a UID/GID other than its own – i.e. if Syncthing on the receiving Mac is running as UID 1000 and GID 1000, for security reasons normal user processes don’t normally have the ability to assign a UID/GID such as 1234/1234 to a file and/or directory.
setcap in Linux is one method of doing just that. The options for macOS are more limited.
Yeah. It is possible I don’t really need this enabled at all for this use case, as, in general, all the files should be owned by the same UID as the one running Syncthing (although I understand if they don’t match, we are back to the initial issue). It is possible that the whole issue was that I turned this on, and the fact that the username existed on the other system with a different UID, caused a problem that normally would have been avoided since I actually want the UIDs to match.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.