Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02-03-17 14:55, Brendan Kearney wrote: > On 03/02/2017 08:43 AM, Kees Bakker wrote: >> On 02-03-17 13:34, Brendan Kearney wrote: >>> On 03/02/2017 05:40 AM, Kees Bakker wrote: On 24-02-17 14:38, Brendan Kearney wrote: > On 02/24/2017 03:33 AM, Kees Bakker wrote: >> On 23-02-17 15:39, Brendan Kearney wrote: >>> On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: > On 02/23/2017 07:32 AM, Kees Bakker wrote: >> On 22-02-17 17:33, Brendan Kearney wrote: >>> On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: > On 02/22/2017 05:23 AM, Kees Bakker wrote: >> On 21-02-17 19:49, Brendan Kearney wrote: >>> On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection >>> does the actual error message say @REALM, or did you substitute that to >>> obscure sensitive info? if it does actually say @REALM, then you are >>> missing a config directive somewhere, that specifies the kerberos realm. >> Be assured that I'm using the real thing. >> getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com >> So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but >> not for another >> user. >> >> [...] >> >> Log when the user is listing the directory >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall >> (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 >> uid=60001 enctypes=18,17,16,23,3,1,2 ' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall >> (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is >> '' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in >> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may >> provide more information) - Can't find client principal keesb@REALM in cache >> collection >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with >> uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being >> considered, with preferred realm 'REALM' >> Mar 2 14:24:00
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 03/02/2017 08:43 AM, Kees Bakker wrote: On 02-03-17 13:34, Brendan Kearney wrote: On 03/02/2017 05:40 AM, Kees Bakker wrote: On 24-02-17 14:38, Brendan Kearney wrote: On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. Be assured that I'm using the real thing. getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another user. Log when root is listing the NFS directory Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com@REALM while getting keytab entry for 'root/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com@REALM while getting keytab entry for 'nfs/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 0) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 Mar 2 14:23:52
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02-03-17 13:34, Brendan Kearney wrote: > On 03/02/2017 05:40 AM, Kees Bakker wrote: >> On 24-02-17 14:38, Brendan Kearney wrote: >>> On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: > On 02/23/2017 09:11 AM, Kees Bakker wrote: >> On 23-02-17 13:51, Brendan Kearney wrote: >>> On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: > On 02/22/2017 10:26 AM, Kees Bakker wrote: >> On 22-02-17 14:05, Brendan Kearney wrote: >>> On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: > On 02/21/2017 10:57 AM, Kees Bakker wrote: >> Hey, >> >> Maybe one of the NFS users on this list could give me a hint what >> could be wrong. I'm not sure if it has any relation with >> FreeIPA/Kerberos. >> >> I've set up an NFS server and I can mount the NFS directory on >> my client. So, I'm >> guessing that setting up Kerberos principal was done correctly. >> >> However, only root can actually access the mounted contents. Any >> other user >> only sees question marks as shown below. >> >> The mount command is simple. >> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >> mount.nfs: trying text-based options >> 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >> >> On the server side /etc/exports looks like this. >> /home*(rw,sync,sec=krb5i,no_subtree_check) >> >> $ sudo mount |grep nfs >> srv1.example.com:/home on /nfshome type nfs4 >> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >> >> $ sudo ls -ld /nfshome >> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >> $ sudo ls -l /nfshome >> total 0 >> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >> >> $ ls -l /nfshome >> ls: cannot access '/nfshome': Permission denied >> $ ls -l / | grep nfshome >> ls: cannot access '/nfshome': Permission denied >> d? ? ?? ?? nfshome >> >> [...] >> >> Continuing story... >> >> I've tried various things in the meantime. I've set up two test environments >> with virtual >> machines (virtualbox). >> * with Fedora 25; this works. >> * with Ubuntu 16.04; I'm getting the same problem (permission denied and >> question marks). >> >> I also looked at the verbose output of rpc.gssd, it gives >> >> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS >> failure. Minor code may provide more information) - Can't find client >> principal keesb@REALM in cache collection > does the actual error message say @REALM, or did you substitute that to > obscure sensitive info? if it does actually say @REALM, then you are missing > a config directive somewhere, that specifies the kerberos realm. Be assured that I'm using the real thing. >> getting credentials for client with uid 60001 for server srv1.example.com >> getting credentials for client with uid 60001 for server srv1.example.com >> WARNING: Failed to create krb5 context for user with uid 60001 for server >> srv1.example.com So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another user. Log when root is listing the NFS directory Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com@REALM while getting keytab entry for 'root/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com@REALM while getting keytab entry for 'nfs/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO:
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 03/02/2017 05:40 AM, Kees Bakker wrote: On 24-02-17 14:38, Brendan Kearney wrote: On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com But the user really did get a TGT. $ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/example@example.com So, still no solution for Ubuntu + freeipa + nfs. BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, there is only any output when root (uid 0) does a NFS directory lookup. When a regular user tries to stat the NFS directory it does not even get to the point where id mapping is done. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 24-02-17 14:38, Brendan Kearney wrote: > On 02/24/2017 03:33 AM, Kees Bakker wrote: >> On 23-02-17 15:39, Brendan Kearney wrote: >>> On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: > On 02/23/2017 07:32 AM, Kees Bakker wrote: >> On 22-02-17 17:33, Brendan Kearney wrote: >>> On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: > On 02/22/2017 05:23 AM, Kees Bakker wrote: >> On 21-02-17 19:49, Brendan Kearney wrote: >>> On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome >>> [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com But the user really did get a TGT. $ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/example@example.com So, still no solution for Ubuntu + freeipa + nfs. BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, there is only any output when root (uid 0) does a NFS directory lookup. When a regular user tries to stat the NFS directory it does not even get to the point where id mapping is done. -- Kees -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server the users are known (through PAM, SSSD). Only user "ubuntu" is a local (/etc/passwd) user. All other users are defined on the IPA server. root@srv1:~# ls -l /home total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root@srv1:~# ls -ln /home total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu On the client, same story root@client1:~# ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 23-02-17 15:39, Brendan Kearney wrote: > On 02/23/2017 09:11 AM, Kees Bakker wrote: >> On 23-02-17 13:51, Brendan Kearney wrote: >>> On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: > On 02/22/2017 10:26 AM, Kees Bakker wrote: >> On 22-02-17 14:05, Brendan Kearney wrote: >>> On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: > On 02/21/2017 10:57 AM, Kees Bakker wrote: >> Hey, >> >> Maybe one of the NFS users on this list could give me a hint what >> could be wrong. I'm not sure if it has any relation with >> FreeIPA/Kerberos. >> >> I've set up an NFS server and I can mount the NFS directory on my >> client. So, I'm >> guessing that setting up Kerberos principal was done correctly. >> >> However, only root can actually access the mounted contents. Any >> other user >> only sees question marks as shown below. >> >> The mount command is simple. >> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >> mount.nfs: trying text-based options >> 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >> >> On the server side /etc/exports looks like this. >> /home*(rw,sync,sec=krb5i,no_subtree_check) >> >> $ sudo mount |grep nfs >> srv1.example.com:/home on /nfshome type nfs4 >> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >> >> $ sudo ls -ld /nfshome >> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >> $ sudo ls -l /nfshome >> total 0 >> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >> >> $ ls -l /nfshome >> ls: cannot access '/nfshome': Permission denied >> $ ls -l / | grep nfshome >> ls: cannot access '/nfshome': Permission denied >> d? ? ?? ?? nfshome >> > sec=krb* means that the user accessing the mount has to authenticate > with a kerberos ticket, and has to be the user or in the group > granted access to the share. from the looks of things, the user did > not authenticate, and that is why the permissions are question marks. > check the kerberos tickets that the user has (klist output). > Otherwise, the ownership might be user and group that the client > machine does not recognize (think posix user/group that is not in > sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com >>> no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed >>> to authenticate. >> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >> What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) >>> there are principals to create and keytabs to be updated on hte NFS >>> sever, if not done already. >> I did create a principal for the NFS server (using ipa service-add) and >> add to the keytab on the NFS server (using ipa-getkeytab) ... >> root@srv1# klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> >> -- >> 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) >> 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) >> 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) >> 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) >> >> Is this what you mean? > yes, if that is done, the server side components should be done for > kerberos. have you set things up in /etc/idmapd.conf so your domain, > REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. >>> NFS needs to know how to map a user object to an ID and groups. identities >>> established by kerberos do not directly translate to users. usually some >>> sort of directory services are leveraged in order to accomplish this, >>>
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server the users are known (through PAM, SSSD). Only user "ubuntu" is a local (/etc/passwd) user. All other users are defined on the IPA server. root@srv1:~# ls -l /home total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root@srv1:~# ls -ln /home total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu On the client, same story root@client1:~# ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root@client1:~# ls -ln /nfshome
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 23-02-17 13:51, Brendan Kearney wrote: > On 02/23/2017 07:32 AM, Kees Bakker wrote: >> On 22-02-17 17:33, Brendan Kearney wrote: >>> On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: > On 02/22/2017 05:23 AM, Kees Bakker wrote: >> On 21-02-17 19:49, Brendan Kearney wrote: >>> On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome >>> sec=krb* means that the user accessing the mount has to authenticate >>> with a kerberos ticket, and has to be the user or in the group granted >>> access to the share. from the looks of things, the user did not >>> authenticate, and that is why the permissions are question marks. >>> check the kerberos tickets that the user has (klist output). >>> Otherwise, the ownership might be user and group that the client >>> machine does not recognize (think posix user/group that is not in sync >>> between the NFS server and the client) >> Thanks for the reply. >> >> In this case the user _is_ authenticated. >> keesb@client1:~$ klist >> Ticket cache: KEYRING:persistent:60001:60001 >> Default principal: ke...@example.com >> >> Valid starting ExpiresService principal >> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com > no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to > authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >> What other grants could be needed? HBAC Rules? >> >> Do I need an nfs principal for the client? (I didn't think so, but many >> HOWTO's say so [2]. Anyway, it >> doesn't help to get access for the user.) > there are principals to create and keytabs to be updated on hte NFS > sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? >>> yes, if that is done, the server side components should be done for >>> kerberos. have you set things up in /etc/idmapd.conf so your domain, >>> REALM, etc are setup? >> I don't think that a change of idmapd.conf (on the NFS server) is needed >> because all host >> names are FQDN and everything is in one and the same REALM. > NFS needs to know how to map a user object to an ID and groups. identities > established by kerberos do not directly translate to users. usually some > sort of directory services are leveraged in order to accomplish this, though > PAM and things like that can be used to. by setting things in idmapd.conf, > you are telling NFS who to translate kerberos identities into usernames, so > ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb@client1$ kinit nfs/srv1.example@example.com Password for nfs/srv1.example@example.com: But I don't have a password for that. Hmm. there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. OK So, it seems to me that all the basics are setup correctly. The mount succeeds. The user has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory entry itself. What puzzles me is that root can see everything, also without a TGT. the mount will succeed, but the user does not have access because NFS
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb@client1$ kinit nfs/srv1.example@example.com Password for nfs/srv1.example@example.com: But I don't have a password for that. Hmm. there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. Furthermore, I'm guessing that the host principle which I got after ipa-client-install is good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I did not do.) # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/client1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/client1.example@example.com (aes128-cts-hmac-sha1-96) [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ http://www.itp.uzh.ch/~dpotter/howto/kerberos -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 22-02-17 14:05, Brendan Kearney wrote: > On 02/22/2017 05:23 AM, Kees Bakker wrote: >> On 21-02-17 19:49, Brendan Kearney wrote: >>> On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome >>> sec=krb* means that the user accessing the mount has to authenticate with a >>> kerberos ticket, and has to be the user or in the group granted access to >>> the share. from the looks of things, the user did not authenticate, and >>> that is why the permissions are question marks. check the kerberos tickets >>> that the user has (klist output). Otherwise, the ownership might be user >>> and group that the client machine does not recognize (think posix >>> user/group that is not in sync between the NFS server and the client) >> Thanks for the reply. >> >> In this case the user _is_ authenticated. >> keesb@client1:~$ klist >> Ticket cache: KEYRING:persistent:60001:60001 >> Default principal: ke...@example.com >> >> Valid starting ExpiresService principal >> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com > no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to > authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >> >> What other grants could be needed? HBAC Rules? >> >> Do I need an nfs principal for the client? (I didn't think so, but many >> HOWTO's say so [2]. Anyway, it >> doesn't help to get access for the user.) > there are principals to create and keytabs to be updated on hte NFS sever, if > not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? > then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb@client1$ kinit nfs/srv1.example@example.com Password for nfs/srv1.example@example.com: But I don't have a password for that. Hmm. >> >> Furthermore, I'm guessing that the host principle which I got after >> ipa-client-install is >> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for >> it, which I >> did not do.) >> # klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> >> -- >> 1 host/client1.example@example.com (aes256-cts-hmac-sha1-96) >> 1 host/client1.example@example.com (aes128-cts-hmac-sha1-96) >> >> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ > > http://www.itp.uzh.ch/~dpotter/howto/kerberos > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. then the user should be able to pull the ticket for auth. Furthermore, I'm guessing that the host principle which I got after ipa-client-install is good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I did not do.) # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/client1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/client1.example@example.com (aes128-cts-hmac-sha1-96) [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ http://www.itp.uzh.ch/~dpotter/howto/kerberos -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) brendan -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Can mount NFS, but user only gets the permission question marks
Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome -- Kees -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
