Are there any Linux updates affecting nfs?

[Raksasas]

Sorry for the general question there and it may be more of an Off-Topic question but my NAS if a FreeNAS system (11.1 U5)... I have been having problems with my NFS shares: I can only read/execute. I can no longer write or modify anything. This has only been going on for about 2/3 weeks now. The nfs shares had been working fine over the last 2 months since I started using NFS instead of CIFS. It seems that all my systems are affected. I am not running nfs on my one, seldom used, windows 7 laptop. The only thing I have mainly done my system is run updates. At this time i don't want to upgrade my freenas to 11.1 U6 until i figure this out. I am tempted to just going back to only SMB(CIFS).

FreeNAS - 11.1 U5
Debian system - Linux X140e 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
Arch (Antergos) system - Linux htpc 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux
Raspberry Pi System - Linux WikiPi 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux

 

[dlavigne]

Were you able to resolve this?

 

[Raksasas]

... Yes, no, not really.. Shoot, I don't really know.

All my systems area Debian based now, plus the Freenas..

What I just tried to do...
share-a, share-b
Freshly loaded system with nfs-common package installed and shares mounted.

• touch share-a/zzzz - worked
• rm share-a/zzzz - worked
• mkdir share-b/ztest - worked
• move existing file - mv share-a/file1 share-b/file1 - Operation not permitted - grrr...

ls -lhn share-a/file1 shows: -rwxrwxr-x 1 1001 9999 share-a/file1
id shows: uid=1000 gid=1000 ... 9999 (The group I created localy and placed the local user in to match the NFS gid's)

I know that the UID's don't match but the GIDs should... So I would think I should be able to do what I want to do with everything in the share.. Am I mistaken? Groups are my friend...

 

[KrisBee]

Short answer to your 1st question is: AFAIK no. Failure of move statement suggests you need to check owner/group/perms on the two FreeNAS datasets. You didn't say if you're using NFSv3 or NFSv4, is id mapping muddying the waters?

 

[Raksasas]

I am guessing that I may not really understand what I am doing with NFS... Hope this helps..

Failure of move statement suggests you need to check owner/group/perms on the two FreeNAS datasets.

On my Freenas system I have:

User I created (minus the root account):
* root
* UID = 0
* raksasas
* UID = 1001
* Primary group = admins
* Aux groups
* wheel
* users
Groups I created:
* users
* GID = 1000
* admins
* GID = 9999
* Permit Sudo = Enabled

Both my datasets should be
* owner (user) = raksasas
* owner (group) = admins
* Mode = owner/group = read,write,execute
* other = all unchecked
* permission type = Unix

my systems: - The only reason my user uid and gid match is be cause they are all debian systems, correct? My focus is the group "admins, 9999" that have matching "gid"
1 - htpc@htpc:~$ id
uid=1000(htpc) gid=1000(htpc) groups=1000(htpc),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),9999(admins)
2 - raksasas@X140e:~$ id
uid=1000(raksasas) gid=1000(raksasas) groups=1000(raksasas),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),9999(admins)
3 - pi@WikiPi:~ $ id
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi),9999(admins)

You didn't say if you're using NFSv3 or NFSv4,

I am not sure... I belive NFSv3(?). mountvers=3?

htpc@htpc:~$ cat /etc/mtab | grep nas-dl
192.168.101.2:/mnt/misfits/downloads /home/htpc/nas-dl nfs rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.101.2,mountvers=3,mountport=641,mountproto=udp,local_lock=none,addr=192.168.101.2 0 0

is id mapping muddying the waters?

I am going to have to say I think so. I am pretty new to NFS. I have been focused on the group ID that way I don't have to focus on the user id's. I do this because of the different systems I run from time to time. I make sure create a group with a gid of 9999 and place the user into that group. Should I be focusing on making sure I have a matching users and UID's on the freeNAS? I don't like the idea of creating a new user every time and littering the system with uid's. Groups are my friend or so I have read...

 

[KrisBee]

Your linux mount maybe version 3, but what are your FreeNAS NFS server settings? Check the server config page in the webui. How are "enable NFSv4" and "NFSv3 ownership model for NFSv4" set?

Post the contents of your exports file with cat /etc/exports

P.S nfsstat -m will show mount details in linux

my systems: - The only reason my user uid and gid match is be cause they are all debian systems, correct?

The reason they match is because they are all debian AND you've used the default id/gid for the first normal account created on each system. They could easily be made to match on a variety of Linux distros, assuming you don't pick values normally reserved for other accounts and don't rely on the default id/gid values of the 1st account on various Linux distros always being the same.

 

[Raksasas]

Your linux mount maybe version 3, but what are your FreeNAS NFS server settings? Check the server config page in the webui. How are "enable NFSv4" and "NFSv3 ownership model for NFSv4" set?

Hope this works.
https://imgur.com/5SdrPuo
https://imgur.com/gXuRa9L

Post the contents of your exports file with cat /etc/exports

from the Freenas:
root@nas:/ # cat /etc/exports
/mnt/misfits/backups
/mnt/misfits/files
/mnt/misfits/pictures
/mnt/misfits/music
/mnt/misfits/downloads
/mnt/misfits/movies

The local system does not have an exports file.

P.S nfsstat -m will show mount details in linux

Not sure if you are asking for the output of this but here you go:
htpc@htpc:~$ nfsstat -m
/home/htpc/nas-dl from 192.168.101.2:/mnt/misfits/downloads
Flags: rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.101.2,mountvers=3,mountport=641,mountproto=udp,local_lock=none,addr=192.168.101.2

/home/htpc/nas-movies from 192.168.101.2:/mnt/misfits/movies
Flags: rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.101.2,mountvers=3,mountport=641,mountproto=udp,local_lock=none,addr=192.168.101.2

The reason they match is because they are all debian AND you've used the default id/gid for the first normal account created on each system. They could easily be made to match on a variety of Linux distros, assuming you don't pick values normally reserved for other accounts and don't rely on the default id/gid values of the 1st account on various Linux distros always being the same.

That is why I have been focused on group's for group collaboration or at least in my case using the system across different systems with the 9999 group. I got the idea from this post.
https://www.rootusers.com/how-to-provide-nfs-shares-for-group-collaboration/
So my datasets are set to group 9999 (admin) and my local system accounts are in a group 9999.

Then again I might be miss understanding something.

 

[KrisBee]

Your FreeNAS NFS server is configured to use NFSv3, so that avoids the complication of id mapping of name string to numeric uid that can happen between a linux client and FreeNAS NFS server.

Authentication for NFSv3 is IP based, so must people would add a "Authorized IP addresses or hosts" to each NFS share definition on FreeNAS, e.g 192.168.101.0/24, in your case. Did you select the "All directories" checkbox on each NFS share definitions?

You'd only see an "export" file on the NFS server, not the client. If does look like you are sharing individual datasets and not multiple directories in a single data set. So assuming you have "unix" set as the "share type" of each of the datasets listed in your exports, then normal unix perms should apply. I'll look through your earlier post again. But had you thought about using the "mapall user" & "mapall group" options in your nfs shares?

 

[Elliot Dierksen]

This is an entry from the way WAY back machine, but this is what NIS (Network Information Services) which was formerly known as YP (Yellow Pages) did. It kept the passwd and group files in sync so that UID's and GID's were in sync across all the systems within the identity domain. I have no idea if it is even still out there. Last time I saw it in use was 20+ years ago. If you are going to have a bunch of disparate Unix systems NFS mounting across a bunch of servers, it might very well be just what you need.

 

[KrisBee]

This is an entry from the way WAY back machine, but this is what NIS (Network Information Services) which was formerly know as YP (Yellow Pages) did. It kept the passwd and group files in sync so that UID's and GID's were in sync across all the systems within the identity domain. I have no idea if it is even still out there. Last time I saw it in use was 20+ years ago. If you are going to have a bunch of disparate Unix systems NFS mounting across a bunch of servers, it might very well be just what you need.

I read that the OP to mean there was one NFS server (on FreeNAS) and multiple separate linux clients in this case. Having established for certain that the OP's FreeNAS NFS sever was running as version 3, the classic NFSv3 setup with shared datasets owned by nobody as user/group and an exports that map all client users to nobody as user/group might suit the OP. This is as per the example in the FreeNAS user guide section 10.2.1 https://doc.freenas.org/11/sharing.html#example-configuration.

 

[Elliot Dierksen]

I read that the OP to mean there was one NFS server (on FreeNAS) and multiple separate linux clients in this case. Having established for certain that the OP's FreeNAS NFS sever was running as version 3, the classic NFSv3 setup with shared datasets owned by nobody as user/group and an exports that map all client users to nobody as user/group might suit the OP.

True, forcing all UID/GID to the same on all files on the NFS mount could work. I guess the question would be if that poses a security problem. This all sounds permission related due to mismatched UID/GID info. Either forcing all restaurants to Taco Bell, or unsnarling the UID/GID stuff and making those consistent across all the servers and clients seem like the only two paths to success that I can see.

 

[Elliot Dierksen]

Just because I can't help myself, a quick Google search turned up this.

https://www.thkukuk.de/nis/

The date on the page is 2012, but it makes me think those things may very well still be available. I will say that the process of getting the passwd and group files in synch to get this going will be difficult and disruptive. It will be nice when complete, but the journey will likely be arduous.

 

[KrisBee]

Suspect OP this is just someone with a home network with a few clients connecting to a single FreeNAS server. So isn't NFSv4 + kerberos5 + whatever overkill? And NIS is in FreeNAS, although going by this page it's pretty involved:
https://www.freebsd.org/doc/handbook/network-nis.html

 

[Raksasas]

Authentication for NFSv3 is IP based, so must people would add a "Authorized IP addresses or hosts" to each NFS share definition on FreeNAS, e.g 192.168.101.0/24, in your case. Did you select the "All directories" checkbox on each NFS share definitions?

Not so simple of a network. .101.#/24 (Static IP) is the services network (servers, printer,etc). .138.#/24 (DHCP) are the "user" systems.

You'd only see an "export" file on the NFS server, not the client. If does look like you are sharing individual datasets and not multiple directories in a single data set. So assuming you have "unix" set as the "share type" of each of the datasets listed in your exports, then normal unix perms should apply. I'll look through your earlier post again. But had you thought about using the "mapall user" & "mapall group" options in your nfs shares?

I have ran across the mapall user/group options. I am a little afraid of using them in case I want to make a share read only to people in the user group.

Suspect OP this is just someone with a home network with a few clients connecting to a single FreeNAS server.

Basicly.

 

[Elliot Dierksen]

Yes, I know NIS isn't simple. I would offer more constructive advice, but it has been 20+ years since I had to do anything with it. Your choices (IMHO) seem to be either mapping all users/groups to the same things, or getting the UID/GID stuff consistent across all the NFS clients. FreeNAS won't care all that much, if it doesn't have the #'s in the passwd/group file. At least I don't think it will.

 

[Raksasas]

I read that the OP to mean there was one NFS server (on FreeNAS) and multiple separate linux clients in this case. Having established for certain that the OP's FreeNAS NFS sever was running as version 3, the classic NFSv3 setup with shared datasets owned by nobody as user/group and an exports that map all client users to nobody as user/group might suit the OP. This is as per the example in the FreeNAS user guide section 10.2.1 https://doc.freenas.org/11/sharing.html#example-configuration.

Lets make sure I am doing this correct:

Select a Storage -> dataset and click the "Edit Permissions" button

• Set the following:
• Owner (user) = nobody
• Owner (Group) = nobody
• Mode = Read, Write, Execute = User, Group \ Unchecked Read, Write, Exactitude = Other
• Permission type = Unix
• Set permission recursively: = checkmarked

Select Sharng -> Unix (NFS) and clicke the the "edit" button

• Click the "advanced" button
• All Direcotrys = checkmarekd
• Mapall User = nobody
• Mapall Group = nobody

Is there anything I need to do on the pc side?

 

[Elliot Dierksen]

Here is what my NFS share looks like. I only share this with ESXi hosts, so all the traffic comes from root.

I could be wrong on this, so double check it. Maproot applies to connections from root (I know, duh). Mapall would map anything to the specified user. The inference I draw from that is that mapall would supersede maproot. I'll confess I only went as far as I needed to go to get my VMWare datastores working, and then my interest level waned rather rapidly....

 

[KrisBee]

I'm afraid my last comment #13 was "postus interruptus". It should have gone to say that NIS may be integrated into FreeNAS/BSD ( i.e. no pkgs to install ) but it isn't Linux clients. At small scale it's just simpler keep accounts in sync on FreeNAS and clients as necessary, or when using NFSv3 choose to squash all connected users to "nobody:nobody".

@Raksasas Your config in #16 above is OK, except you don't need to give the nobody group write perms on the share owned by ""nobody:nobody".

Looking back I still can't spot why that "mv" statement failed. But its probably staring me in the face. Although I did notice you added a "user" group with id of 1000 on FreeNAS. That's a potential point of confusion when it's the id of a secondary group of some of your linux accounts and the id conflicts with the standard "user" group account on Linux , which has an id of 100.

[edited error in last para ... ]

 

[Raksasas]

@Raksasas Your config in #16 above is OK, except you don't need to give the nobody group write perms on the share owned by ""nobody:nobody".

I am going to crate a new dataset and share so I am not monkeying with the originals... yet.

Dataset = test1
Setting the following:
Create dataset

• Name = test1
• Comment = test1
• Sync = inherit (standard)
• Compressions level = inherit (lz4)
• Share type = unix
• Enable atime = Inherit on
• ZFS Deduplication = inherit (off)
• Case Sensitivity = insensitive

Edit permissions

• Owner (user) = nobody
• Owner (Group) = nobody
• Mode = User = Read, Write, Execute \ Group = Read, Execute \ Other = Unchecked Read, Write, Execute
• Permission type = Unix
• Set permission recursively: = enabled

Select Sharng -> Unix (NFS) and add new share

• Path = /mnt/misfits/test1
• Comment = test1
• All directories = enable
• Read only = unchecked
• Click the "advanced" button
• All Direcotrys = enabled
• Read only = unchecked
• Quiet = unchecked
• Maproot = no changes made
• Maproot Group = no changes made
• Mapall User = nobody
• Mapall Group = nobody

Sorry, @KrisBee. Just wanting to make sure that I am correctly do everything.

Looking back I still can't spot why that "mv" statement failed. But its probably staring me in the face. Although I did notice you added a "user" group with id of 1000 on FreeNAS. That's a potential point of confusion when it's the id of the primary group of some of your linux accounts and the id conflicts with the standard user account on Linux , which has an id of 100.

I am not really following on this as I do not see an id of 100.
Freenas side:
% id
uid=1001(raksasas) gid=9999(admins) groups=9999(admins),0(wheel),1000(users)

Standard system:
htpc@htpc:~$ id
uid=1000(htpc) gid=1000(htpc) groups=1000(htpc),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),9999(admins)

 

[KrisBee]

@Raksasas For NFS share set up, I'd set dataset "Case Senstivity" to "sensitive".

The Last point was my error, that should have read "it's the id of a secondary group of some .. " [now edited]. This is where you may have gone astray re: your use of group ids. You can put linux users into a secondary group which matches an owner group on a FreeNAS dataset, but those linux users will use their primary groups when performing actions on mounted datasets.