bluehz, all my perms are showing to be my user name and group unknown after the transfer using either samba or rsync. I have set both servers to uid = 0 and gid = 0. And yes, both sides are run as root.

I narrowed it down to the problem being with HFS and that is why I was hoping someone could confirm that, in fact, perms cannot be changed on that file system. Please, if anybody has a spare empty partition at hand, format it to HFS standard and try to 'chown root:wheel' or something on it and let me know if you are successful.

I have not tried the HFS test myself - but I did run across this dated article from 2000:

http://www.mit.edu/people/wsanchez/papers/USENIX_2000/
this is an interesting article on HFS and Linux

http://www-sccm.stanford.edu/Student...ADME.html#toc1

Hmm. The caption you posted would seem to suggest that HFS doesn't hold Unix-style metadata. However, I have found it to work fine on a local linux box when using an HFS exchange partition. I still don't know why a networked HFS partition wouldn't work though.

The test format that I requested would only take literally seconds to do. It's real simple using Disk Utility on Mac OS X. Format back to HFS+ is just as quick too. I know it's not likely that someone readily has an empty partition for this test though. But hopefully someone does and will post here eventually as that is the only full proof of this that I can be sure of. The smoke test, if you will.

Ok - I tested this out creating an HFS formatted disk image. User/group and permissions are definitely borked on HFS disk. Here's the technique I used:I also tried the above process logged in as root, mounting the disk as root, and running rsync as root and still got the same results.

Thank you for confirming!
 

You have definitely confirmed what I had thought, that perms aren't going to work on an HFS volume. Thanks bluehz. Your results were the same as mine.

There's just one more thing to try if you still have the volume and that would be to try a chown on it to see if you were able to change the owner and or group to something else than what it currently is. I'm almost certain that it would not work, saying something like operation not supported. Either that or it might seem to do the job but when you check to see, it would not have.

I still don't know or understand why HFS won't work over the network but does on the same linux box. It's a mystery.

That's interesting stuff, bluehz. I just realized that if you create two identical disk images; one HFS, and the other HFS+, then mount them and do "Get Info" on them, then look under the "Ownership & Permissions" section, only the HFS+ volume has the option for "Ignore ownership on this volume". It's checked by default, and I can only change permissions on the volume if I uncheck it. Otherwise, it acts like the HFS volume (and won't budge at all when I try to change the group from "unknown" to something else).