On Mon, May 09, 2016 at 11:00:06AM -0400, Chuck Lever wrote: > > > On May 6, 2016, at 12:13 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Fri, May 06, 2016 at 09:23:40AM -0400, Chuck Lever wrote: > >> > >>> On May 5, 2016, at 10:44 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > >>> > >>> On Thu, May 05, 2016 at 05:01:58PM -0400, Chuck Lever wrote: > >>>> After some IRC discussion with Bruce, we think the answer > >>>> is "this is not supported in the current Linux NFS server." > >>>> > >>>> The server does not have a way to determine which service > >>>> principal to use for NFSv4.0 callback operations. It picks > >>>> (probably) the first nfs/ service principal in the server's > >>>> keytab for all callback operations. > >>>> > >>>> Thus if a Linux NFS server has a keytab, clients can mount > >>>> it with NFSv4.0 (and any security flavor) only on the i/f > >>>> whose hostname matches the name of the nfs/ service > >>>> principal in that server's keytab. > >>> > >>> One correction: the mount should still work correctly. The server just > >>> won't grant any delegations to the client. > >> > >> Unfortunately this is not the case. > > > > Ugh, OK, that's worse than I thought. I guess you can work around it on > > the server side with "echo 0 >/proc/sys/fs/leases-enable". > > Google can find this e-mail thread, but would like me to > open a bug report on bugzilla.linux-nfs.org as well, Bruce? Up to you. I'll confess to mostly ignoring upstream bugzilla until it sends me email. By the way, were you using gss-proxy? (What distro?) Did it take any special configuration to get the basic protocol working with multiple principals, beyond just creating the keytabs? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
