On 11/11/2020 10:54, Jason Keltz via samba wrote:> Hi Louis, > I've looked into that and I'm not sure how this would be done? > By the way, even with your NFS translation fix (which doesn't work for me because gssproxy), do you do this before accessing root files..? > sudo root > kinit -k 'host$' >OK, after a bit of a battle, I now have a Centos 7 Unix domain member mounting an NFS share from a Devuan NFS4 server. The actual mount wasn't a problem, it was getting the NFS server to work ? I used Samba AD DC's for the authentication, a Unix domain member as the NFS server and a Centos 7 Unix domain member as the NFS client. I did minimal setup on the Centos machine. Rowland
On 11/12/2020 8:17 AM, Rowland penny via samba wrote:> On 11/11/2020 10:54, Jason Keltz via samba wrote: >> Hi Louis, >> I've looked into that and I'm not sure how this would be done? >> By the way, even with your NFS translation fix (which doesn't work >> for me because gssproxy), do you do this before accessing root files..? >> sudo root >> kinit -k 'host$' >> > OK, after a bit of a battle, I now have a Centos 7 Unix domain member > mounting an NFS share from a Devuan NFS4 server. > > The actual mount wasn't a problem, it was getting the NFS server to > work ? > > I used Samba AD DC's for the authentication, a Unix domain member as > the NFS server and a Centos 7 Unix domain member as the NFS client. I > did minimal setup on the Centos machine.Hi Rowland, The problem wasn't getting NFS to work - it was getting NFS "root" access to work between a CentOS 7 client and CentOS 7 server? (AKA no_root_squash in /etc/exports). Finally, after a significant amount of effort, I figured that out last night. In my case, I needed to add a realms section for realm AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows: [realms] ? AD.EECS.YORKU.CA = { ??? auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/ ??? auth_to_local = DEFAULT ? } This allows root on "J1" to "really" be root.? Additional of the first line are required for each system.? The DEFAULT line is required.?? Lots of fun let me tell ya. Jason.
On 12/11/2020 13:27, Jason Keltz via samba wrote:> > On 11/12/2020 8:17 AM, Rowland penny via samba wrote: >> On 11/11/2020 10:54, Jason Keltz via samba wrote: >>> Hi Louis, >>> I've looked into that and I'm not sure how this would be done? >>> By the way, even with your NFS translation fix (which doesn't work >>> for me because gssproxy), do you do this before accessing root files..? >>> sudo root >>> kinit -k 'host$' >>> >> OK, after a bit of a battle, I now have a Centos 7 Unix domain member >> mounting an NFS share from a Devuan NFS4 server. >> >> The actual mount wasn't a problem, it was getting the NFS server to >> work ? >> >> I used Samba AD DC's for the authentication, a Unix domain member as >> the NFS server and a Centos 7 Unix domain member as the NFS client. I >> did minimal setup on the Centos machine. > > Hi Rowland, > > The problem wasn't getting NFS to work - it was getting NFS "root" > access to work between a CentOS 7 client and CentOS 7 server? (AKA > no_root_squash in /etc/exports). > > Finally, after a significant amount of effort, I figured that out last > night. > > In my case, I needed to add a realms section for realm > AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows: > > [realms] > ? AD.EECS.YORKU.CA = { > ??? auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/ > ??? auth_to_local = DEFAULT > ? } > > This allows root on "J1" to "really" be root.? Additional of the first > line are required for each system.? The DEFAULT line is required.?? > Lots of fun let me tell ya. > > Jason. > >Define what you mean by 'really root' ? The root user is a Unix user and, as such, has nothing to do with AD (or NFS). If you can login into a Unix domain member, you should be able to use root and if you login into a Windows domain member, then try to use root, it should go 'root ? who is that ?' So, when you log into a Unix domain member, what isn't working ? Rowland