I’ve been battling with the SFU NFS server for a while now. One mystery I haven’t solved with it it’s mapping of the ‘group’ owner of a file.
In Unix, every file has an associated user and group, and these are stored in the file system. In Windows, each file has an owner SID, which can either be a user or a group (at least, that is all that is revealed in the UI).
So here’s the mystery: when the nfs client asks for the user and group of a file, how does the SFU NFS server decide? I found that if I set the owner of a file (on the windows side) to a user’s SID, then the “user” part of the answer is the UID as specified in the User Mapping component. However, the group part always returns -2 which is convention to mean the nobody user.
Interestingly, if I create a file from the nfs client (Linux) with some UID and GID, the server accepts this information, and somehow stores it. Further accesses to the that file return the correct UID and GID, even across mounts and unmounts.
More annoyingly, a file created on the windows side by a user in the Administrator group always gets its owner set to the Administrators group SID. So when NFS servers up this file, it tries to map the Administrators group as a user, and always fails.
That aside, though, it is clear from the client-side file creation example that Windows is capable of storing the ‘group’ associated with a file somewhere. It’s just that this information seems to be inaccessible and unmodifiable.
Anyways, getting this straight just became such a pain, that I decided to install Ubuntu on the machine instead.

1 Comment

  1. Marc

    Reply

    Hi there, I realize this post is 4+ years old, but I am now in the exact position you describe. That is, how do you determine and/or set the GID on a file when you create it on the Windows side and serve it up via SFU! I don’t suppose you found any solution (besides scrapping it and using linux instead!)
    Thanks a lot,
    Marc.

Leave a comment

Your email address will not be published. Required fields are marked *