Re: NFS MOUNT blues

Hi Patrik,

"What exactly do you mean with "has never worked"?" If I try to mount a Nfs
folder using an User with an Id not matching the "other" side the mount is
rejected.

Tia
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno sab 5 apr 2025 alle ore 17:19 Patrik Schindler <poc@xxxxxxxxxx>
ha scritto:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.