| Summary: | MCC access nfs shares does not show available nfs shares | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Herman Viaene <herman.viaene> |
| Component: | RPM Packages | Assignee: | Olivier Blin <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davy.defaud, guillomovitch |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | MGA5TOO | ||
| Source RPM: | drakx-net nfs-utils? | CVE: | |
| Status comment: | |||
Same in MGA6-Beta3. The strange thing is that actually there is nothing wrong with the nfs installations on both sides (server and client) since at the CLI mount -t nfs <FQDN>:/<exported map> /mnt/<some map> works OK and the mounted map and files therein can be displayed in dolphin. As a side note: I have the same in PCLinuxOS. Assigning to drakx-net maintainer and adding maintainer of nfs-utils in CC. CC:
(none) =>
guillomovitch I have similar troubles too. Hereâs what I experienced: - My NFS server is a CentOS 7 exporting via NFSv4 (no problem with NFSv3). - NFS mount from MGA5 works perfectly with a manual mount command. - autofs "lazy mount" with special "-host" mount doesnât work on MGA5 (see bug #16195), but does work from a CentOS 6 or 7 NFS client. - alternative autofs "lazy mount" with auto.net script doesnât work with both MGA5 and CentOS 6 as it's using "showmount -e" command which is having the same problem you discribed. - but, "showmount -e" command does work from a CentOS 7 client. The main difference between CentOS 6 (& MGA5) and CentOS 7 is that there is a new daemon named gssproxy that *seems* to act as a bridge between showmount and the NFSv4 server... CC:
(none) =>
davy.defaud I cannot reproduce this anymore in the MGA6 testing ISO's. Is OK with M7 client. Status:
NEW =>
RESOLVED |
Try to get access to NFS server from MCC. The NFS-server (Mageia 4) is shown, but none of the two available shares. The frustrating thing is that I never got it working on a MGA-4 client, that it worked out of the box in the MGA -5 Alpha versions, and now in MG5-B2 it does not again. And the cause is the same: RPC timed out. From the CLI on the M5 client: # rpcinfo <serverIP> program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /var/run/rpcbind.sock portmapper superuser 100000 3 local /var/run/rpcbind.sock portmapper superuser 100024 1 udp 0.0.0.0.140.87 status 487 100024 1 tcp 0.0.0.0.168.1 status 487 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100003 4 tcp 0.0.0.0.8.1 nfs superuser 100227 2 tcp 0.0.0.0.8.1 nfs_acl superuser 100227 3 tcp 0.0.0.0.8.1 nfs_acl superuser 100003 2 udp 0.0.0.0.8.1 nfs superuser 100003 3 udp 0.0.0.0.8.1 nfs superuser 100003 4 udp 0.0.0.0.8.1 nfs superuser 100227 2 udp 0.0.0.0.8.1 nfs_acl superuser 100227 3 udp 0.0.0.0.8.1 nfs_acl superuser 100021 1 udp 0.0.0.0.155.245 nlockmgr superuser 100021 3 udp 0.0.0.0.155.245 nlockmgr superuser 100021 4 udp 0.0.0.0.155.245 nlockmgr superuser 100021 1 tcp 0.0.0.0.207.7 nlockmgr superuser 100021 3 tcp 0.0.0.0.207.7 nlockmgr superuser 100021 4 tcp 0.0.0.0.207.7 nlockmgr superuser 100005 1 udp 0.0.0.0.141.113 mountd superuser 100005 1 tcp 0.0.0.0.231.254 mountd superuser 100011 1 udp 0.0.0.0.2.191 rquotad superuser 100011 2 udp 0.0.0.0.2.191 rquotad superuser 100011 1 tcp 0.0.0.0.2.191 rquotad superuser 100011 2 tcp 0.0.0.0.2.191 rquotad superuser 100005 2 udp 0.0.0.0.148.83 mountd superuser 100005 2 tcp 0.0.0.0.181.85 mountd superuser 100005 3 udp 0.0.0.0.159.27 mountd superuser 100005 3 tcp 0.0.0.0.201.208 mountd superuser and # showmount -e <serverIP> rpc mount# showmount -e <serverIP> rpc mount export: RPC: Timed out export: RPC: Timed out