NFS problem with UIDs

ptitvert · 06-04-2018, 12:56 PM

I use the following setup:

NFS Server (Ubuntu 16.04 LTS)

nfs-common 1:1.2.8-6ubuntu1.2
nfs-kernel-server 1:1.2.8-6ubuntu1.2
user: test (uid=1300)

NFS Client

nfs-common 1:1.3.4-2.1
user: testmf (uid=1350)

On the client side, the user test exists with the same UID as in the server side. But I need to use the user testmf and not the test one.

I have read a lot documentation, and answers from StackOverflow/StackExchange, and for some reasons nothing works for me.

One of the many answers is to change the file /etc/idmapd.conf.

So here it is on both side:

Server

Code:

[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
# Domain = localdomain

[Mapping]    
Nobody-User = nobody
Nobody-Group = nogroup

On the client side:

Code:

[General]
Verbosity = 9
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
# Domain = localdomain
Domain = example.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = static

[Static]
test@nfsserver.example.com = testmf
test@192.168.0.1 = testmf
test@nfsserver = testmf
test@example.com = testmf

And I use such command to mount the directory on the client:

Code:

mount 192.168.0.1:/home/test/my_exp_dir /home/testmf/my_imp_dir

And when I do a ls -l /home/testmf/my_imp_dir I get something like that:

Code:

-rw-r--r-- 1 test test  326025780 May  9  2017 allCountries.zip

and NOT

Code:

-rw-r--r-- 1 testmf testmf  326025780 May  9  2017 allCountries.zip

If I do a this point a touch testfile I get that:

Code:

-rw-r--r-- 1 test test  326025780 May  9  2017 allCountries.zip
-rw-r--r-- 1 testmf testmf      0 Jun  9  18:57 testfile

Or ls -ln

Code:

-rw-r--r-- 1 1300 1300  326025780 May  9  2017 allCountries.zip
-rw-r--r-- 1 1350 1350          0 Jun  9  18:57 testfile

I tried to increase the level of verbosity, and nowhere in my logs I can see the mapping of users from one UID to another like I could see on some answers. The two things I could see is that the kernel setting /sys/module/nfs/parameters/nfs4_disable_idmapping was set to Y and even after changing to N, nothing seems to work.

The second thing that I have found is the 2 entries doesn't exist on my client server:

/proc/net/rpc/nfs4.nametoid
/proc/net/rpc/nfs4.idtoname

And I don't know how to add it, especially if the nfsidmap is not available.

I have read that I also need to restart the idmapd service after that change. But in Debian 9 there it is not possible... Or at least I have not found how to do it...

I have also changed the file /etc/default/nfs-common to set the variable NEED_IDMAPD=yes and it doesn't do anything, even after a reboot...

So my question is maybe quite dumb, but how can I activate nfsidmapd on Debian Stretch? I am really out of option, search keywords and the official documentation of Debian is not really helpful here, except if I am totally blind!

Thank you in advance for your help.

jlinkels · 06-05-2018, 07:23 AM

Maybe a stupid question, but do you have to use NFSv4? For networks not exposed to the public internet, and where users simply keep themselves to the rules (that is stay out of something if they are not entitled to be there, and refrain from hacking attempts) I don't see the added value. Except added complication.

jlinkels

ptitvert · 06-05-2018, 08:49 AM

The idea was that we have a historical server (serverA) with NFS v4. The exported directory is own by user test.
We try to share a server (serverB) with several teams, and each team cannot share the user test, and we want each team to use their own user (testmf, testcore, testjs, testff, ...)
And if we mount the exported directory that has the test owner into the new server (serverB), then we must ensure that the assigned user testmf can access to the data with the corresponding permissions. That's why I wanted to use the idmapping to achieve that. If the permission are mapped to the user test, then it won't correct on what I am expecting.

I've choosen NFS because it was already there, and it is easy to setup.

If NFSv4 or NFSv* is not the correct tool. Then what would be a better tool?
Even if serverA is not the newest server version, I have possibility to install other tools for sharing directory. Would SMB a better choice?

jlinkels · 06-05-2018, 09:53 AM

As you have notices, NFS was simple but that has changed with NFSv4. You are not the first one...

I don't think SMB is easy to use either because SMB is a Windows protocol and Windows and Linux permissions to not integrate very well.

The old fashioned Unix way would be to use NFS, but version 3. And set permissions based on group membership. That was how Unix was designed.

You would have to add all users to a single group. So testmf, testcore and test itself should be in the same groups among all hosts. Say gtest. On the NFS server you would assign ownership and RW permissions to the group. Files would look like this:

Code:

-rw-rw-r-- 1 test gtest  326025780 May  9  2017 allCountries.zip
-rw-rw-r-- 1 test gtest      77766 May  9  2017 foo.txt

If one of your other users adds a file, it would look like this:

Code:

-rw-rw-r-- 1 test      gtest  326025780 May  9  2017 allCountries.zip
-rw-rw-r-- 1 test      gtest      77766 May  9  2017 foo.txt
-rw-rw-r-- 1 testcore  gtest      12345 May  9  2017 bar.txt

But still, everyone which is member of the gtest group can read or write those files

It is important that the numeric gid of gtest is identical on all machines. Either you use central authentication, or you just make sure you give gtest the same ID on all hosts. Essentially, you create the group gtest on all hosts with the same ID, and then you add the users to this group. And yes, users must also have the same UID on both the host and the server.

Central authentication makes this process much smoother. But it might be easier to set up everything manually before spending time with central authentication.

If you require that files created by any user are owned by test, you can set the sticky bit on the directory which holds that files.

Directories should have at least rwx permissions for the gtest group.

jlinkels

ptitvert · 06-05-2018, 11:10 AM

I did that yesterday after spending hours on making NFS works for me... I used the group permissions.
We are in the process to have a centralized authentication (freeipa), and nearly 90% of all our servers are already "converted". Except this serverA :-P

So I did implement your suggestion, but was a bit frustrated that my idea was difficult or not possible to do with NFS :-(

After reading your answer, and everything I've read in internet... apparently what I want to do is just not possible per se. And need to go to the "traditional" unix permission for that.

Nevertheless thank you. I lost a bunch of time, but I've learned the limitation of some tools that I was using, and that experience is invaluable! :-)

MadeInGermany · 06-07-2018, 02:41 AM

I think only NFSv4 allows remapping of UIDs.
NFSv3 only has remapping for UID 0 (root squash). Further there might be a mount option to remap all UIDs to one UID.

In a professional environment, for realizing a group access it is better to work with a common group, umask 002, and g+s bit in the directories.
Why? The UID is retained, important for accounting. And other users can be easily excluded.