Project

General

Profile

Bug #26386

Be consistent with NFSv3 ownership model for NFSv4

Added by Caleb St. John about 1 year ago. Updated 12 months ago.

Status:
Resolved
Priority:
Critical
Assignee:
William Grzybowski
Category:
OS
Target version:
11.0-U6
Seen in:
11.0-U5
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
SMJ-829-86739
Migration Needed:
No
Hide from ChangeLog:
No
ChangeLog Required:
No
Support Department Priority:
0

Related projects 1 project

Description

When setting up NFSv4 mounts with sec=sys, checking the option "NFSv3 ownership model for NFSv4:" it sets the following values.

1. nfsuserd_enable="no" in rc.conf.local
2. vfs.nfsd.enable_stringtouid=1

Issues:
1. nfsuserd daemon does not stop
2. on reboot or if the nfsd process is restarted. nfsuserd starts even though rc.conf.local is set to "no" (this is happening in stock freeBSD 11.0 as well)
3. manually killing nfsuserd does not allow NFSv3 UID/GID mappings to function correctly

Reproducible:
1. create root dataset
2. create nfs share and point to dataset
3. check "Enable NFSv4" under the NFS service
4. verify that "nfsuserd" is running (service nfsuserd status)
5. check "NFSv3 ownership model for NFSv4:" under the NFS service
6. verify that "nfsuserd" is running (it should not be running at this point)
7. manually kill nfsuserd (service nfsuserd stop)
8. mount nfs share from linux client "mount -t nfs4 -o tcp truenas:/mnt/dataset local-dir/"
9. cd /local-dir/ && touch testfile && chown localuser:localgroup testfile from linux client
10. permissions are initially changed but ~5-10seconds later the permissions are changed back to the nobody:nogroup permissions

History

#1 Updated by Ash Gokhale about 1 year ago

nfsuserd      nfsuserd    result
running       running
server        client
---------------------------------------------------------------
yes           yes         Correct users, even with inconsistent uid
yes           no          nobody, nogroup all over the shop ( disparate domain.name )
yes           no          (same domain.name)
no            yes         Correct users as long as uid's are aligned

However it seems that the middleware never starts nfsuserd in head tracking 11.1-beta unless >16 groups is checked due to rc.conf.local writing 'no' in to the /tmp/rc.conf.local file at boot time,
this is also observed in TN 11.0internal4.u4.
This is corrected by using 'restart' to the arg in plugins/service.py: 770ish which internally uses 'onestart'.
Meanwhile /etc/rc.conf.local:566 has new and different logic echos of the startup routine that can be out of sync with the database.
rc.conf local only starts nfsuserd when the >16 groups support is checked; which is confusing and is inconsistent with the use v3 semantics

These two methods should get DRY'd or merged.

#2 Updated by Ash Gokhale about 1 year ago

  • Status changed from 50 to Screened
  • Target version set to TrueNAS 11.1-U1

Regenerating the rc vars at database commit time should normalize this race.

#3 Avatar?id=14398&size=24x24 Updated by Kris Moore about 1 year ago

  • Seen in changed from 11.0-U4 to 11.0-U5

#4 Avatar?id=14398&size=24x24 Updated by Kris Moore about 1 year ago

  • 1 added project (FreeNAS)

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore about 1 year ago

  • Status changed from Screened to Unscreened
  • Assignee changed from Ash Gokhale to William Grzybowski

William / Vladimir,

Wanted to bring this one to your attention. Ash believes its a race condition somewhere with new middleware in how rc.conf knobs are getting set and then services started at boot.

#6 Updated by William Grzybowski about 1 year ago

  • Status changed from Unscreened to Screened

#7 Updated by William Grzybowski about 1 year ago

DRY'ing or merging methods between shell script and python is not trivial, we will not be doing that.

#8 Updated by William Grzybowski about 1 year ago

rc.conf local only starts nfsuserd when the >16 groups support is checked; which is confusing and is inconsistent with the use v3 semantics

Does that make sense to you, Ash? http://sprunge.us/PAEj

#9 Updated by William Grzybowski about 1 year ago

ping

#10 Updated by Ash Gokhale about 1 year ago

wrt: http://sprunge.us/PAEj
It fixes the behaviour from the UI ; but does it result in correct result when 'serivce nfsd restart` is requested? Since we don't regen the /tmp/rc.conf.freenas until reboot+database diff we still have a parallel config source that's out of sync.

#11 Updated by William Grzybowski about 1 year ago

Ash Gokhale wrote:

wrt: http://sprunge.us/PAEj
It fixes the behaviour from the UI ; but does it result in correct result when 'serivce nfsd restart` is requested? Since we don't regen the /tmp/rc.conf.freenas until reboot+database diff we still have a parallel config source that's out of sync.

Why should it? 'service nfsd restart' is an unexpected user interaction
In which scenarios would that be called?

#12 Updated by Ash Gokhale about 1 year ago

It's not uncommon for support to operate filers in production from the shell where the ui is non operational or for debugging argument changes in protocols. Customers use this as well.

I'm open to a better way to do this.

#13 Updated by William Grzybowski about 1 year ago

Ash Gokhale wrote:

It's not uncommon for support to operate filers in production from the shell where the ui is non operational or for debugging argument changes in protocols. Customers use this as well.

I'm open to a better way to do this.

You guys should be schooled of using internal middleware commands: e.g. midclt call service.restart nfs

Either way, if NFSv3 model is checked/unchecked rc.conf.local should be regenerated and using `service` should work, no? I guess I dont see the issue.

#14 Updated by Ash Gokhale about 1 year ago

I support your proposed change and will look in to educating myself of the midctl commands.

#15 Updated by William Grzybowski about 1 year ago

  • Status changed from Screened to Ready For Release

#16 Updated by Dru Lavigne about 1 year ago

  • Subject changed from NFSv3 ownership model is broken to Be consistent when restarting NFS

#17 Updated by Dru Lavigne about 1 year ago

  • Target version changed from TrueNAS 11.1-U1 to TrueNAS-11.1-RC2

#18 Updated by Dru Lavigne about 1 year ago

  • Target version changed from TrueNAS-11.1-RC2 to 11.1-RC2

#19 Updated by Dru Lavigne about 1 year ago

  • Target version changed from 11.1-RC2 to 11.1-RC3

#20 Updated by Dru Lavigne about 1 year ago

  • Status changed from Ready For Release to Resolved

#21 Avatar?id=14398&size=24x24 Updated by Kris Moore about 1 year ago

  • Status changed from Resolved to 19
  • Target version changed from 11.1-RC3 to 11.0-U6

William - Couple customers have made enough noise about this one, can you backport it to 11.0-U6 please? Thanks!

#22 Updated by William Grzybowski about 1 year ago

  • Status changed from 19 to Needs Developer Review
  • Assignee changed from William Grzybowski to Vladimir Vinogradenko

#23 Updated by Vladimir Vinogradenko about 1 year ago

  • Status changed from Needs Developer Review to Reviewed by Developer
  • Assignee changed from Vladimir Vinogradenko to William Grzybowski

#24 Updated by William Grzybowski about 1 year ago

  • Status changed from Reviewed by Developer to Ready For Release

#25 Updated by Dru Lavigne 12 months ago

  • Subject changed from Be consistent when restarting NFS to Be consistent with NFSv3 ownership model for NFSv4

#26 Updated by Dru Lavigne 12 months ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF