both running with same user id and the user has admin privileges.
chown -R for all files in ~/Documents - all owned by the same user
standard APFS file system on both laptops (case insenstive as the default)
No samba, no android, no nothing. Just bog standard sync between two macOS laptops. Local LAN, local sync.
Both laptops are in “send/receive” mode.
Still keep getting errors like this:
setting metadata: lchown ~/Documents/.syncthing.xx.java.tmp: operation not permitted
Even after deleting all xtended attributes for this file (xattr -c), still get the same error. This is beyond frustrating. Have tried rescanning, pausing and restarting, tried everthing. These errors don’t go away…
However, syncthing is running on macOS, under my user name with the exact same privileges as me (me being the admin user in question).
Syncthing launched as a .app, owned by me, running as me. Syncthing does not have its own account and is not giving up privs and/or running as a different user (confirmed using Activity Monitor).
syncthing has privs to do whatever I can do - and I can do anything since all the files are owned by me, under my own documents folders and reconfirmed owned by me (using chown -R).
Here, specifically, for one of the files in question:
ls -l ~/Documents/.syncthing.xx.java.tmp
-rw-r–r-- 1 javadesigner staff
And btw, as an aside, the actual user id for my user account (verified using id -u) is the same number on both computers.
Apparently your user does not have the needed privileges to say extended attributes. As @calmh already wrote, you should probably turn off syncing of external attributes. It is not enabled by default for reasons which are good for most users.
Do you see the permissions I posted as well as the fact the I am in fact the admin user account of the machine ?
Did you also see I can change any attribute I want via the xattr utility on the command line and that works successfully - including deleting all extended attributes, via xattr -c ?
Even after this, I get this error when I try to sync. So do you have any actual information to share instead of vague platitudes ? After all, I want to sync extended attributes, since that is (1) useful and (2) supported on macOS..
The files are owned by me (user id: 501 on both machines, admin user, verified by id -u on macOS terminal). In fact, there is no other user (ignoring macOS system users) on this machine except me - I am the admin user (ie I already have elevated privs, although not root).
What is the underlying issue that suggests I should not sync ownership ? This is not NFS where root is squashed to nobody. This is macOS on a APFS filesystem (identically case insensitive on both laptops) with the same exact user on both laptops and the same uid/owner for all the files in question (~/Documents)
This sounds like a bug in syncthing perhaps ? Your doc here doesn’t talk about macOS at all but does talk about POSIX-POSIX (which is what this case should be)
If you have only one user account on each machine, then what should the “sync ownership” setting be good for? Any file will always be owned by the sole user, no need for Syncthing trying to touch that.
The operating system restricts access to the system function for changing ownership. This is probably not granted to the user account. So when Syncthing tries to call the function, it fails, but was unneeded anyways.
In essence, what @calmh said. Turn off that option and see if it helps. Then we’ll see how to help further.
Ok - turning off that option did work and everything syncs successfully now. Still feels weird this was happening in the first place though. The following article talks more xattr’s on macOS (and perhaps sheds a partial light on the issue):
Thanks again to everyone for responding and for all your help. I would request you add a document section specific to macOS on this issue.
Ownership has nothing to do with xattrs and I don’t see why the two gets mixed together in this thread. Setting ownership, the chown call mentioned in the error, requires elevated permissions: syncOwnership — Syncthing documentation
Syncthing, when running as a normal user account, doesn’t have permission to alter file ownership.
Not running as a normal user account but a admin user account.
On unix systems (including macOS), chown for your own files (that you already own) never requires elevated privs (for any kind of account)
In this case, the sync issue was for files already owned by the same admin user, with the exact same user id on both machines, so why would there be a chown issue ?
I don’t really understand. Other than the need to be right.
you’re running as your own user account. And trying to change owner to yourself of files you already own. You wouldn’t have permission to change ownership to another account. You wouldn’t have permission to change other owners files to your account.
Why do you need to sync owners?
I don’t understand what you’re trying to accomplish.
Are you not interested in making syncthing bug free and a better product ?
If indeed what I’m doing is a-ok, then shouldn’t syncthing just simply work without crapping out ? And if it is crapping out - when there is a setting that should theoretically have no effect (and/or work seamlessly) - then that is an internal bug somewhere.
Fixing bugs - or least reporting them to the dev team - helps everyone don’t you think ?
Your account is a normal account. Being ”admin” on macOS just means it is permitted to use sudo to become root, which is the ”non-normal” account.
You could argue that Syncthing doesn’t need to run chown at all when the files are uid 501 and Syncthing is running as uid 501, and you’d be right, but you’d also just mask the problem that ownership syncing isn’t in fact working other than by random chance.
Thanks, that makes a lot of sense, but from the perspective of a new user, who downloads and plays with syncthing (like me) - why error out if this option happens to be checked?
In this case, there isn’t any need to error out at all - maybe the error should only happen when there is a underlying reason for the error to happen.
Just my 0.02 cents to reduce the onboarding friction for new users and increases the perception of reliability (also for new users). Especially given the fact that chown (for all users, normal or root) works flawlessly if you already own your files and syncthing (on the mac) does not seem to be changing it’s effective uid (euid) or dropping privs at runtime…so this makes the chown failure all the more confusing..
For a new user, fiddling with options under “Advanced” may not be the best idea. Unless you have read the corresponding documentation (linked right there) and really understood what the “elevated permissions” requirement means.
Thanks - but just FYI, there is no macOS section in the documentation for this particular issue. Only for linux and windows and there are no instructions on what elevated permissions would mean or require when double clicking a macOS app.
I hear you on the docs, feel free to propose improvements. That said, it’s really not “linux” that is documented there, it’s “unixes”, which covers everything from macOS to OpenBSD. Apple has layered a bit of their own terminology and concepts on top which may not always be helpful in recognising what’s going on under the hood, though.
Perhaps it’s become clear but I think syncthing did just what it was supposed to do. You requested to sync ownership while running from an account that does not permit such changes.
In my mind it’s better to get the error immediately than to get the error at some point down the road when there’s actually a change to make.
That said it does seem like a possible optimization to change this behavior but it would mask the permissions issue until some later point in time. I don’t sync owners for the same reason you thought it should work. (I already own the files on both systems.)
That said, it’s really not “linux” that is documented there, it’s “unixes”, which covers everything from macOS to OpenBSD. Apple has layered a bit of their own terminology and concepts on top which may not always be helpful in recognising what’s going on under the hood, though.