×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hello Greg,
Am 05.05.2023 um 17:04 schrieb Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>:
Patrik, I didn't feel like anyone provided a "terse" response 😊 (I'm a very "direct" person).
Phew! ;-)
Jim, I'm confused about the UID/GID statement below... I was under the impression that NFS doesn't use "user id" to authenticate?
Stock NFSv3 "authenticates" only by source IP address (and probably if the originating source port is < 1024). NFSv3 is not using "user based authentication" as we know it from Windows (SMB) or Macs (AFP), but machine based authentication (although crude). The *authorization* to actually do something with a file on a mounted NFS server is something different then authenticate (to prove to the server you are in fact you). As every so often, this approach has advantages and drawbacks.
NFSv4 introduced optional Kerberos authentication, but I never took my time to tinker with that.
Allow me to elaborate:
Unix associates a file with a user ID (the owner), and a group ID. Those IDs are "translated" by text files /etc/passwd and /etc/group to actual user and group names. This is not some special feature of NFS, but an intrinsic function of traditional Unix.
NFS carries this forward over the network.
Assume you have your NFS server with a user poc having the group IP 501. There is a file which is owned by this ID 501. On the local system, this resolved to user poc.
Now, there's another machine, being NFS client to the former system. The system administrator also created a user poc. But since the user "greg" was created before, greg now has the ID 501, and poc 502 on the new system.
If you look at the directory listing (ls -l) from the second machine, the file appears to be owned by greg and not poc, because the user ID is associated with the file. Not a textual user name.
This is what Jim was trying to explain: You need to "sync" user IDs on the NFS server and on the NFS clients. I don't know if one can change the user IDs in Windows AD. They're auxiliary data, and Windows uses "SIDs" internally instead. And I don't know if one can change the Unix user ID of a IBM i *USRPRF.
(At least) on Linux, an add-on application has been created the "ugidd" (user-group-id-daemon), doing some magic to "bend" NFS mounted user IDs according to the local user database instead of blindly relying on user IDs. I don't know if such a facility exists on Windows, or IBM i.
HTH.
:wq! PoC
midrange.com
