Hello Marco,
Am 05.04.2025 um 15:43 schrieb Marco Facchinetti <marco.facchinetti@xxxxxxxxx>:
Hi Patrik, just as I wouldn't dare contradict Birgitta about SQL, the same goes for networking with you. :-)
Thank you. :-)
That said, I have to say that my experience with NFS is exactly what Jim describes. If the user IDs don't match, access is denied. Creating a Linux user with the same name as the IBM i user has never worked.
What exactly do you mean with "has never worked"? What were the access rights on the file you've tried to access on the server side?
Okay, let's prove my assertion.
I have created a directory on a Linux NFS Server within an NFS export "/vmfs", root:root, 777. Mounted that exported /vmfs on IBM i with default options. Linux says:
Apr 5 16:44:00 myhostname rpc.mountd[2260]: authenticated mount request from xx.xx.xx.xx:943 for /vmfs (/vmfs)
On IBM i, my UID is 105, GID is 101. On the Linux side, this ID maps to a system user _apt, and system group crontab.
Created a text file in that folder on the Linux side, containing just "hello" as a string, and chown'ed it user ftp (id 113), group root (0), mode 644.
Said file belongs to an UID and GID which is not me on IBM i. But because the "other" permission bits permit reading, I should be able to read that file.
Test: I can read the content of that file with "cat" from IBM i qsh. ✅
Test: Because "other" permission bits allow just reading, I should not be able to write to that file.
echo "testcontent" > file fails: Permission denied. ✅
Changed mode to 640 on the Linux side.
Test: I should no longer be able to read that file.
Permission denied on read with "cat". ✅
Changed permission bits to 446 (!) (user and group have only read access, others may write in addition to read). I shold now be able to write to that file.
echo "testcontent" > file works with no error. ✅
Reading the file on Linux shows indeed "testcontent" has been written.
NFS works exactly as I've asserted/predicted. I have actually tested my assertions to be correct. As said, It's not only matching UIDs and GIDs to allow access. You must also consider the permission bits.
I'm now convinced that Gad's issue with IBM i locked files not being released is not related to permissions at all, but some malfunction in newer Windows NFS implementations. He said, it worked before the upgrade, so the reason is quite apparent, isn't it?
Even considering that we will soon no longer use NFS (it seems to be poorly supported in the Cloud and the serviced storage costs too much) a little culture wouldn't hurt and I would therefore be curious to understand why the username mode doesn't work.
Please read my post about the heritage of NFS, where I explained just that. Usernames usually do not matter to NFS, but UIDs do. Group names work likewise.
I do see that 7.3 has a daemon type *RGY, which should provide name translation. I dimly remember that name translations "on the fly" might be something which is only specified for NFS v4.
:wq! PoC
midrange.com
