right, I confirm this too, the topic of this bug should be ânfs fails to mount shares because rpcbind is not startedâ, patch welcomed

CC: (none) => shikamaru

until mandriva 2007.1 the nfs worked out of the box. Since the 2008.0 to make nfs share working i had to do the settings above and since the 2010.0 i had to define the hostname of the server too, otherwise the mount failed without any explanation (just a "mount failed" message).

Yesterday evening there was the same problem to connect via nfs /searching a server with the MCC.

Today I controlled the packages, all nfs-packages are installed.
Also nfs-common and rpcbind are activ.

In the past I established directly the nfs-mount on my mandriva system directly with an entry in fstab, someting like this:
"192.168.2.155:/video /nfs/video nfs rsize=32768,wsize=32768,nosuid,soft,bg 0 0" 

This works as well on my Mageia!

In the MCC I can see the established nfs connection.

But the "Find servers" says nothing, although there is an other nfs-server!

CC: (none) => magnus.mud

I think the tool "lost control" after searching a new server.

I can see my "direct" nfs-mount with its option and can it umount.

But after "Find server" there is no posibility to do any function except for the entries in the menu bar.

It seems like the not working find box in rpmdrake (bug 30)

i think it's just that if there are no servers, you can't use any of the buttons anyway...

Yes, in the menu bar and the Finish-Button.

But not the umount for my displayed nfs-mount, after you press the "Find server".

There is the same Problem in cooker

The bug is still present (beta2).

The system finds no (existing) nfs-server.

But I can add a nfs-mount in the fstab

Some more Infos:
If I disable the local firewall, I get the nfs-server.
If I enable the local firewall and allow there NFS Server, 
I don't get my nfs server! I Think this is a bug.

How can I get more detail informations what the system is doing?

Magnus: the nfs protocol needs alot of ports and some of them are dynamic by default.

The find server button does odd things, like hang when the firewall is on. and perhaps we should have a way if you "allow nfs server" that a number of ports are being opened and some perhaps static so that it effectively allows it?

(In reply to comment #10)
 
> The find server button does odd things, like hang when the firewall is on. 
Ok, this is the explanation for the non-finding.

Perhaps, system can write a message, that the firewall is enabled?

and
> perhaps we should have a way if you "allow nfs server" that a number of ports
> are being opened and some perhaps static so that it effectively allows it?
This would be very nice :-)

I will look in the next days, if wireshark say something to me, when I try to search a nfs server.

On the other side I'm astonished that I can use the nfs-mount (via fstab)
although the firewall is enabled!

So it is a workaround (for those who use the internal firewall) to disable the firewall, set the nfs-mounts and then enable the firewall.

now on cauldron I find my nsf-server.
But it takes a long, long time.

Tomorrow I will verify it on a Magei 1

This is the same bug as I have reported on Mandriva:

https://qa.mandriva.com/show_bug.cgi?id=63416

CC: (none) => wilcal.int

I tried Mageia 1 32-bit to see if the NFS mount
works on that and it does not.  :-((  Both 32 & 64
are with the Gnome GUI. The 64-bit mounts but the
GUI interface is exxxxtreeemmmly slow so somehow
the NFS mount is effecting X in that mode.

With this mornings updates, including a new kernel,
this bug seems to have gone away. I am running 64-bit
Mageia. Lets see if it stays away.

Today, 2011-08-01, I can still mount NFS shares.
But, I do have to manually edit /etc/fstab and
put in the LAN IP address of the server. In this
case it's 192.168.0.08. Once I do that the NFS
share mounts to my local workstation. The server
is a Mandriva 2010.2 32-bit box.

@AL13N
@William

There is a drakxtools maintainer, now (tv). Is the bug still there in Cauldron and Mageia 1?

CC: (none) => m.van.waes

afaik yes.

but this also ties in with that a firewall needs extensive modifications that don't always work due to some passive ports. it would be nice if installing NFS-server would modify the ports automagically or somehow ask or something. or maybe keep the ports static.

My Mageia 1 64-bit install, NFS mount, continues to work
just fine with the hand modified /etc/fstab file.

I have the same problem but related to setting NFS Shares through the MCC. I could establish shares very easily in earlier Mandriva 2008 setups and then with later versions of Mandriva and now with Mageia setting NSF Shares through the MCC fails. 

I had filed a bug on Mageia in 2009! Yikes! A long time ago! (https://qa.mandriva.com/show_bug.cgi?id=52252)

Is this part of the same problem? We had a discussion of this on the Mageia discuss list (http://comments.gmane.org/gmane.linux.mageia.user/5394) and there was some sort of indication to a resolution to the problem in the last message by Rama Space Ship where he says:

=============
My question was not to provide a workaround, but to help identify where the problem is.
It seems that you have a name resolution problem, not a NFS problem. If I take the fstab file you use when starting that thread:
- the setting of NFS shares uses "linux-5" as remote hostname (question to an expert: how does the tool find this name?)
- but "linux-5" is not found as a remote host (question to Marc: is "linux-5.local" found as a remote host, e.g. can you ping linux-5.local?)
If your remote host is named "linux-5", "linux-5.local" should work as it should be published by the ZeroConf mechanism (avahi).

So if this works, the best workaround could be to use "linux-5.local" in the fstab file as it does not depend on static IP addresses.

The fix would be that the setting of NFS shares uses ZeroConf hostnames.

> Somehow, the setting up of NFS shares and fstab was broken in older versions of Mdv and never fixed.
It was probably broken when the ZeroConf mechanism was used, as the hostnames got ".local" appended. 
================

It would be great to have this fixed so that users could set up NSF shares right out of the box. Right now it just doesn't work.

Marc

CC: (none) => marc

Same here, on updated mga1-64
Had to disable firewall if i want to configure via mcc.
NFS itself works with firewall enabled.

This is with Mandriva 2010.2 as NFS host.
And i am too getting horrible speed, a stable 1,2 MiB/s acording to system monitor, and this on gigabit ethernet...
My mandriva laptop is getting twice that speed over wireless from same host...

Will switch to a new server running mga1 next week.

CC: (none) => fri

(In reply to comment #21)

> Had to disable firewall if i want to configure via mcc.
> NFS itself works with firewall enabled.

There's one piece of this that
is very illusive. Connection of
client to NFS server is also
dependent on processor speed of
CPU. Sometimes you have to slow
down the connect process to
ensure that the NFS connect is
made. On fast computers sometimes
you have to add the following:

/etc/sysconfig/network-scripts/ifcfg-eth0  the line :
LINK_DETECTION_DELAY=5

Then increase or decrease the delay
as needed. Slower platforms seem
to need less delay. But not always.
I've got an old Celeron 1.8Mhz that
connects every time with no delay.
My i7 needs a setting of 5 and
still I have to manually make the
mount. This is even with no software
firewall at all.

I await the Mageia 2 ISO's as a stake
in the ground to start my testing.

I've had enough experience, and installs,
of Cauldron Alpha 1 that I am convinced
that this problem is behind us. Alpha 1
clearly installs the necessary RPM's,
finds the NFS server on the LAN and mounts
the NFS share correctly. I have not had to
manually modify /etc/fstab on any of my
Mageia 2 Alpha 1 installs.

what about the firewall on your NFS server?

All within my local LAN there is
no firewall anywhere. Completely
disabled. This is my private
residence and I'm the only one
living here so no chance of
intrusion. The Router is the
new NETGEAR WNDR4000-100NAS N750
so it's pretty tough.

that's not what i meant...

if i have firewall on my NFS server, and i enable NFS in firewall, the NFS mounting drakwizard still has troubles due to some ports being random and discovering

(In reply to comment #26)

> if i have firewall on my NFS server, and i enable NFS in firewall, the NFS
> mounting drakwizard still has troubles due to some ports being random and
> discovering

Yep, that's specifically what I found with
Mandriva NFS Server/Client years ago. And
one of the reasons I turned the firewalls
on everything completely off.

Unfortunately Cauldron is once again not
being able to mount NFS shares. We were
doing so well on this then something
happened about a week ago.

MCC -> Network Sharing -> Access NFS shared drives

Sees the share but is unable to mount. Manually
modifying /etc/fstab this time does not help.
mount -t nfs source mount
also does not work. I'm gonna keep this
on this bug ( 207 ) but this time it may
not be the same problems.

All the firewalls on the server and client on
the LAN are turned off.

I try to see the nfs share by mcc without succes (it cant find the server)
A simple mount command can mount the nfs share without problem
Mageia 1

(In reply to comment #29)

> I try to see the nfs share by mcc without succes (it cant find the server)
> A simple mount command can mount the nfs share without problem
> Mageia 1

Share with me the mount command you are using.

FWIW this is a very long running problem with
Mandriva. Seems it's been around for years.
I've always had to either manually mount
or manually edit /etc/fstab to get it to
work. I was VERY encouraged to see M2A2
work so well then discouraged when it
stopped working.

Also FWIW I usually do a clean install, and
complete update, of Cauldron once a week to
catch these issues. I'll keep doing that
every week till release in April.

Thanks

i used the command:
mount 192.168.0.27:/home/dglent/data2 partage/
and it worked so i added in fstab the:
192.168.0.27:/home/dglent/data2 /home/xenia/partage nfs rw 0 0

but when i enter the showmount command:
[root@localhost dglent]# showmount --all
All mount points on localhost.localdomain:
192.168.0.11:/home/dglent/data2

i dont understand where it find the ip 192.168.0.11 as the ip of the nfs server (my machine) is the 192.168.0.27

OK here's what I tried here this morning

in a su terminal
mount 192.168.1.2:/home/wilcal/databank /home/wilcal/shares/sherman
does not work and here's what that looks like in a terminal:

[wilcal@localhost ~]$ su
Password: XXXXXXXXXXX
[root@localhost wilcal]# mount 192.168.1.2:/home/wilcal/databank /home/wilcal/shares/sherman
[root@localhost wilcal]# 

Here's my command in fstab that does not work
but does just fine on /etc/fstab Mageia 1:

192.168.1.2:/home/wilcal/databank /home/wilcal/shares/sherman nfs rsize=8192,wsize=8192,nosuid,soft 0 0

Heres what happens when I use my fstab command in a terminal:

[wilcal@localhost ~]$ su
Password: XXXXXXXXXXXX
[root@localhost wilcal]# mount 192.168.1.2:/home/wilcal/databank /home/wilcal/shares/sherman nfs rsize=8192,wsize=8192,nosuid,soft 0 0
Usage: mount -V                 : print version
       mount -h                 : print this help
       mount                    : list mounted filesystems
       mount -l                 : idem, including volume labels
So far the informational part. Next the mounting.
The command is `mount [-t fstype] something somewhere'.
Details found in /etc/fstab may be omitted.
       mount -a [-t|-O] ...     : mount all stuff from /etc/fstab
       mount device             : mount device at the known place
       mount directory          : mount known device here
       mount -t type dev dir    : ordinary mount command
Note that one does not really mount a device, one mounts
a filesystem (of the given type) found on the device.
One can also mount an already visible directory tree elsewhere:
       mount --bind olddir newdir
or move a subtree:
       mount --move olddir newdir
One can change the type of mount containing the directory dir:
       mount --make-shared dir
       mount --make-slave dir
       mount --make-private dir
       mount --make-unbindable dir
One can change the type of all the mounts in a mount subtree
containing the directory dir:
       mount --make-rshared dir
       mount --make-rslave dir
       mount --make-rprivate dir
       mount --make-runbindable dir
A device can be given by name, say /dev/hda1 or /dev/cdrom,
or by label, using  -L label  or by uuid, using  -U uuid .
Other options: [-nfFrsvw] [-o options] [-p passwdfd].
For many more details, say  man 8 mount .
[root@localhost wilcal]# 


Now changing that slightly to better conform to the mount command format:

[wilcal@localhost ~]$ su
Password: 
[root@localhost wilcal]# mount -t nfs 192.168.1.2:/home/wilcal/databank /home/wilcal/shares/sherman rsize=8192,wsize=8192,nosuid,soft 0 0
Usage: mount -V                 : print version
       mount -h                 : print this help
       mount                    : list mounted filesystems
       mount -l                 : idem, including volume labels
So far the informational part. Next the mounting.
The command is `mount [-t fstype] something somewhere'.
Details found in /etc/fstab may be omitted.
       mount -a [-t|-O] ...     : mount all stuff from /etc/fstab
       mount device             : mount device at the known place
       mount directory          : mount known device here
       mount -t type dev dir    : ordinary mount command
Note that one does not really mount a device, one mounts
a filesystem (of the given type) found on the device.
One can also mount an already visible directory tree elsewhere:
       mount --bind olddir newdir
or move a subtree:
       mount --move olddir newdir
One can change the type of mount containing the directory dir:
       mount --make-shared dir
       mount --make-slave dir
       mount --make-private dir
       mount --make-unbindable dir
One can change the type of all the mounts in a mount subtree
containing the directory dir:
       mount --make-rshared dir
       mount --make-rslave dir
       mount --make-rprivate dir
       mount --make-runbindable dir
A device can be given by name, say /dev/hda1 or /dev/cdrom,
or by label, using  -L label  or by uuid, using  -U uuid .
Other options: [-nfFrsvw] [-o options] [-p passwdfd].
For many more details, say  man 8 mount .
[root@localhost wilcal]# 

Neither of these worked.

Did we recently make an update to the mount command?

Many thanks for working on this long term issue. Why
did M2A2 work so wonderfully well when it was released
and now not work at all?

Going back into my Mandriva notes of the past
there was a time when an fstab nfs mount would
work on some computers and not on others. It
seemed that on fast computers it was more
likely that the nfs mount would not work. So we
constructed a little connect delay to slow the boot
process down on faster computers. That command
looked like this:

To /etc/sysconfig/network-scripts/ifcfg-eth0  I added the line :
LINK_DETECTION_DELAY=5

ifcfg-eth0
----------
DEVICE=eth0
BOOTPROTO=dhcp
METRIC=10
LINK_DETECTION_DELAY=5

"5" for a 5 second delay

Mandy 2009 would not fstab mount NFS at boot on fast computers
without this delay added to ifcfg-eth0. Once the computer
had completely booted, and the network established,
if you opened a terminal and manually mounted the
NFS share it would mount every time. I don't think
this is the same problem. And putting that command
into ifcfg-eth0 on M2A2 did not help.

Also FWIW on all my working computers I always put
the Gnome desktop image on the NFS shared drive so
that when I turn it on I can immediately tell if
the NFS mount was working. I'm now retired but on
my last job everyones workstation was really working
off an NFS mount. That was about 20 workstations.

Also FWIW I am testing, writing and sending this
on my M2A2 test system that for the most part works
just fine and updated successfully today.

While testing current Cauldron I came upon this issue yet again.

The problem I am having is because the mount command cannot resolve the host name it is trying to use.

My remote NFS server has the hostname zero.localdomain, when drakxtools searches for NFS shares it drops the domain name and displays the host as 'zero'
When it tries to mount the share it uses the path zero:/path/to/share

If I do not have an entry in the /etc/hosts table for the host then it cannot resolve the hostname.

Avahi could resolve the hostname 'zero.local' , but it cannot resolve 'zero'.


So IMO drakxtools should either use IP addresses instead of hostnames when mounting a share, or else avahi should be able to resolve hosts without domain names.

CC: (none) => derekjenn

Remote mount of NFS directories has worked
now successfully for M2B2 so I am going
to put this one to bed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Re opening because Mageia 2 RC still has problems with the NFS GUI in MCC

I have taken a look at the code and come up with some proposed solutions.

1/ The time it takes to search for NFS servers is far too long
/usr/lib/libDrakX/fs/remote/nfs.pm contains the subroutine find_servers
This subroutine spawns two child processes which each call 'rpcinfo-flushed -b mountd 3'
The rpcinfo command returns the names of local nfs servers within a few seconds, but the child process then takes another 60 seconds to time out. The parent process cannot finish until the children have.

To fix this I have rewritten the subroutine to kill the child processes after a fixed interval long enough to ensure all hosts have replied. I have also removed a redundant while loop that only had one pass. 

2/ Mounting NFS shares always fails unless DNS is able to resolve the host name.
When the GUI mounts NFS shares or writes the fstab file it always uses the host name (without domainname) discovered during the search. So if the local DNS cannot resolve the hostname or the host is not in /etc/hosts, then mounting always fails.
  Fixing this was easier than I thought it would be.
 In Mageia1  'rpcinfo-flushed -b mountd 3' returns hosts in the format
xxx.xxx.xxx.xxx hostname.local   

So I patched nfs.pm to leave the domain name in the string returned.
Now when mounting NFS shares the DNS lookup will go to avahi to resolve the name and mounting succeeds.  (Assuming the nfs server is running avahi)

3/ A lot of user problems with the NFS GUI is because people do not realise the firewall will interfere with searching for servers. rpcinfo uses random port numbers so it is not possible to selectively open a port.
To avoid confusion I patched smbnfs_gtk.pm  to add some text to the nfs info box to advise people to open the firewall during server searching.

Proposed patches to follow.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Created attachment 2281 [details]
Patch to tome out nfs server search

Proposed patch to time out child processes when searching for nfs servers and to return the domain name as well as the hostname to facilitate name discovery with avahi.

This patch applies to both Mageia 1 and Mageia2

My perl experience is not great so I am sure it could be written better :)

Created attachment 2282 [details]
Patch to add information to NFS GUI

Proposed patch to add information to the NFS GUI advising user to open up the firewall during search for NFS servers

still, this is quite awesome, i'm sure someone will take a look after mga2 is released... this sounds really helpful!

also, it would be nice if we by default have a fixed port, so we can set up our firewall for it

Created attachment 2315 [details]
Patch to add firewall dialogue to draknfs

Third proposed patch for NFS. This time a cosmetic patch for draknfs to add a dialogue advising users to open up the firewall after adding an NFS share.

We (and Mandriva) get a lot of forum questions about NFS where people have simply forgotten to open the firewall.

(In reply to comment #40)
> Third proposed patch for NFS. This time a cosmetic patch for draknfs to add a
> dialogue advising users to open up the firewall after adding an NFS share.

I think this is a good idea.

Thanks.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Still valid for Mageia 2

Version: Cauldron => 2

I would default to what Derek chooses.
Either change it in 2 or make the
change in Cauldron only.

Still valid for mga2 (64-bit), 

but with a disabled firewall (on the local machine) I see the nfs-shares

Not sure whether this is the same bug?

A fresh install of Mageia 2 and I had similar problems.  I was advised to try "service prcbind start" which did indeed allow the mounts.  This was followed by "systemctl enable rpcbind.service" which, I'm told, will make this a permanent change.

CC: (none) => annew

This bug is still valid in Mageia2. I still have to modify fstab to get my NFS to work.

I have test it on 32 and 64bit boxes at my house. (4 boxes)

Cheers,

Marc

(In reply to comment #47)

> This bug is still valid in Mageia2. I still have to modify fstab to get my NFS
> to work.

Agreed. I still have to insert the IP of the
NFS server in the NFS command in /etc/fstab.
Then in su terminal: mount -a

There seem to be several issues mixed in this bug report.

1) FSTAB NFS mounts fail because rpcbind is not started at boot after systemd conversion.

2) FSTAB NFS mounts fail because they are attempted before the network (and DNS) is fully available.

3) FSTAB NFS mounts fail because something is using the wrong domain for hostname resolution.

4) FSTAB NFS mounts fail because the firewall is blocking NFS activity.

All of these require different fixes.  Could you please clarify which of them is/was actually the case and which of them still fail ?

CC: (none) => ftg

(In reply to comment #49)

> There seem to be several issues mixed in this bug report.....
> All of these require different fixes.  Could you please clarify which of them
> is/was actually the case and which of them still fail ?

I have seen and experienced all four of your
stated issues with NFS mounts over the years.
Also in Mandrake/Mandriva and now Mageia.
And, they seem to come and go with time.

The biggest problem is the firewall of the
client. I take the entire firewall down
on an NFS client and rely in the Routers
firewall for the LAN. Somehow this must
be conveyed to the user.

I also think that we have to somehow state
how the NFS server is set up. Here is my
menu on how to set that up:

For sharing a local directory using NFS:
MCC: Network Sharing -> Share drives and directories using NFS
installs nfs-utils
MCC: Share drives and directories using NFS
     Add -> Directory: /home/wilcal/databank
            Access: *
            User ID: No user UID mapping
            Anonymous user ID: (blank)
            Anonymous Group ID: (blank)
            Advanced: all no
            
Note that some years ago some computers would not
bring up the network for some time therefore when
an NFS client would attempt to connect with the
NFS server that would fail. So I had to put a delay
in /etc/sysconfig/network-scripts/ifcfg-eth0
Here's the command I used:

LINK_DETECTION_DELAY=5

for some reason that requirement has gone away.
Even my i7 based machine has no problem nor my
slowest Celeron 1.7Ghz machine with Mageia 2.

The one remaining issue for me is the NFS comment
in /etc/fstab. I still have to manually edit that
to read as follows:

192.168.1.2:/home/wilcal/databank /mnt/sherman nfs rsize=8192,wsize=8192,nosuid,soft 0 0

that after creating the /mnt/sherman directory.
Putting the IP address of the NFS server in and
removing whatever the Mageia NFS client setup
process puts in.

Somehow the naming of the NFS servers network ID
and shared directory needs to be clarified. This
may have some influence on the clients mounting.
Here is what I do for that:

NFS network host naming setup
-----------------------------
change line 1 in /etc/hostname to sherman
change line 1 in /etc/hosts to sherman
add HOSTNAME=sherman in /etc/sysconfig/network

"sherman" being the name of the NFS server

But still with all of this I have to manually
edit the NFS comment line in /etc/fstab

This is a very old issue(s) going way back into
even Mandrake. And issue(s) is many and varied.
Feel free to comment on any of my processes.
Comments are warmly welcome.

(In reply to comment #50)
> (In reply to comment #49)
> 
> > There seem to be several issues mixed in this bug report.....
> > All of these require different fixes.  Could you please clarify which of them
> > is/was actually the case and which of them still fail ?
> 
> I have seen and experienced all four of your
> stated issues with NFS mounts over the years.
> Also in Mandrake/Mandriva and now Mageia.
> And, they seem to come and go with time.

Yes, I read about the workarounds above.  But this bug is filed against *cauldron*, so the question is which of these problems still exists there ?

I ask because I use NFS mounts with unqualified hostnames and have done so for years without seeing any of these problems except, recently, for (1).  Of course, I didn't configure NFS via MCC, so it's possible that something it does produces the effects you see.

If (2) is occurring, then either systemd is running whatever does fstab mounts before network-up, or if this only happens with your NIC, the driver is reporting network-up prematurely.

If (3) is happening, then either your domain name is incorrect in resolv.conf or else the mount is being attempted before it is set.

If (4) is happening, then you need to find the Shorewall messages in syslog which indicate what's being dropped and why.

It's great that you found workarounds for yourself, but I guarantee you that nobody is going to change Mageia to insert 5-second delays in interface-up or turn off shorewall for NFS clients, so any hope of fixing this rests on understanding exactly what is happening and why.

I have another more globular comment to make
and please share your thoughts. Is NFS even
relevant? I've been told that most networks
use Samba not NFS so putting a lot of effort
into NFS is kind of a waste.

I'm retired but the last company I worked for,
for 10-years, used a small LAN and did indeed
use NFS. The LAN had about 30 clients and
multiple servers. A combination of Solaris
and Linux ( Mandriva ) servers. All Mandriva
clients.

> comment 51:
> I didn't configure NFS via MCC

I suggest this is an important point. The
setup of NFS server/client(s) in Mandrake,
Mandriva and now Mageia has never been
clean. Considering the above should the
effort be put into making the process clean
and simple?

(In reply to comment #51)

> But this bug is filed against *cauldron*, so the question is which
> of these problems still exists there ?

I believe that it does. I also suggest that the ultimate
workout should remain in cauldron. If the final fix can
be retroactively applied to Mageia 1/2 then do so but
do not constrain the work out to be retroactive.

My impression is that NFS is richer in function and certainly more Unix-friendly than SMB.  As an aside, OS/2 originally supported SMB (what it called "File and Printer Sharing"), but IBM added an NFS component anyway.  Since that event is 15+ years old, it may or may not be relevant.

I'm not a maintainer, just an interested party, in addition to which I use cauldron exclusively, so whether or not a fix is backported really isn't of interest to me.  

I could give suggestions for diagnosing the problems described above, but it's hardly worth the effort unless we know that they still exist.

May be it is necessairy to add this bug as a feature for Mageia 3 in the wiki.
"Make a NFS share by MCC GUI with more details and options for the user" 

Actually i can acces the NFS share only from the terminal.

(In reply to comment #49)
1/ I have tried it out in an Mga2 vbox. I had no trouble with rpcbind not starting after install or on the next boot. It does not seem to be a current issue.

2/ I have a network of several PCs and vbox images all using NFS mounts. None of them have problems with the network coming up or with availability of DNS.

3/ The 'something' in question is draknfs As far as I am aware the issues with NFS in Mageia are all concerned with the GUI in MCC One of the things it does wrong is the way it builds the entry to go in fstab. It uses the command
rpcinfo-flushed -b mountd 3  to discover remote NFS exports. rpcinfo provides the IP address, the host name, the domain, and the name of the share. draknfs then puts just the hostname into fstab so the share can only mount if the host can be resolved by a local DNS server or is /etc/hosts. I proposed in Attachmnent 2281 that the fstab line should contain 'hostname.local'  the special domain 'local' can be resolved by DNS using avahi. This would work in any network with avahi enabled.

4/ The firewall does not prevent mounting NFS shares with fstab. It blocks the discovery of remote NFS exports using rpcinfo-flushed.  Rpcinfo expects replies over UDP on a random port number. With the firewall enabled the GUI simply does not find any remote exports.

I have been looking at alternative ways to discover remote NFS exports that works from behind a firewall. Nmap looks as if it may do the trick

This discovers my NFS4 exports OK. I do not know if it works for NFS3 as well.

$ nmap -p 111 --script=nfs-showmount 192.168.1.0/24

Starting Nmap 5.51.6 ( http://nmap.org ) at 2012-06-18 20:36 BST
Nmap scan report for 192.168.1.10
Host is up (0.0032s latency).
PORT    STATE  SERVICE
111/tcp closed rpcbind

Nmap scan report for 192.168.1.22
Host is up (0.00034s latency).
PORT    STATE SERVICE
111/tcp open  rpcbind

Nmap scan report for 192.168.1.24
Host is up (0.0024s latency).
PORT    STATE    SERVICE
111/tcp filtered rpcbind

Nmap scan report for 192.168.1.33
Host is up (0.0059s latency).
PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-showmount: 
|   /home/derek/Pictures 192.168.1.0/24
|   /home/derek/Music 192.168.1.0/24
|_  /var/lib/mythtv/recordings 192.168.1.0/24

Nmap scan report for Derek.lan (192.168.1.45)
Host is up (0.0015s latency).
PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-showmount: 
|_  /home/derek/raspberry_pi 192.168.1.0/24

Nmap scan report for 192.168.1.251
Host is up (0.0097s latency).
PORT    STATE SERVICE
111/tcp open  rpcbind

Nmap scan report for O2WirelessBox.lan (192.168.1.254)
Host is up (0.0027s latency).
PORT    STATE    SERVICE
111/tcp filtered rpcbind

Nmap done: 256 IP addresses (7 hosts up) scanned in 2.69 seconds

OK, so basically this bug is about (1) discovery in draknfs, and (2) a sort of oddball case of mounts involving NFS servers outside of the client's resolvable domains.

I'm not exactly sure how (2) occurs in a network topology scenario owned by someone who needs a GUI to set up NFS, but I guess it has something to do with avahi-style zero-configuration networking.

I would say that draknfs should be using the FQDN just in case.  Considering that the other drak tools have no problem putting UUIDs in /etc/fstab, the space certainly shouldn't be a problem.

And either the shorewall config should be modified to allow rpcinfo-flushed to work, or a replacement should be found.  Your nmap approach looks promising.

(In reply to comment #56)
[...]
> This discovers my NFS4 exports OK. I do not know if it works for NFS3 as well.
> 
> $ nmap -p 111 --script=nfs-showmount 192.168.1.0/24
[...]

ooh, i like your thinking, but isn't this needed to run as root?

I am reporting from the point of view of a user. 

* I set my NFS shares through the MCC (or I used to do this in Dolphin->right-click on file->Properties->Share

* I then use MCC to locate and mount the shares

This is the most likely route any user would take to set up shares on their LAN. For some reason, it used to work on Mandrake and, then, for some reason, this quit working and still does not work properly on Mageia 1 or 2. (BTW ... I also turn off my Firewall on my LAN boxes.)

I wonder why there seems to be so much trouble in the MCC "finding" the NFS share ip's and then inserting these into the fstab? When I modify fstab manually, of course, the shares do work. 

The MCC route should the the one to fix as this is really the only alternative that any user (inexperienced at working in Konsole) has.

It is also a marketing loss when a function does not work properly in the MCC.

Marc

Created attachment 2475 [details]
Proposed patch using nmap

Here is a new proposed patch using nmap to discover NFS shares

* checks rpcbind is running
* works from behind a firewall
* requires perl-Nmap-Parser to be installed
* if host name can be resolved puts host.domain into fstab else puts IP address into fstab
* if firewall is open to avahi will include avahi when resolving
* searches for shares on all private subnets in routing table.

It is also considerably quicker than the current method.

It is still advisable to open the firewall to avahi to aid host name resolution, but it is not essential. If the host name cannot be resolved it will use IP address in fstab.

I am sure the code can be a lot tidier/efficient.

Attachment 2281 is obsolete: 0 => 1

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

(In reply to comment #61)
> 
> @ the reporter and persons in the cc of this bug:
> 
> If you have any new information that wasn't given before (like this bug being
> valid for another version of Mageia, too, or it being solved) please tell us.
> 
> @ the reporter of this bug
> 
> If you didn't reply yet to a request for more information, please do so within
> two weeks from now.
> 
> Thanks all :-D

I have no additional information.

i wonder if this is correctly assigned or if the patch has been committed, or if there needs to be more work done or not... what is exactly decided here?

(In reply to comment #63)
> i wonder if this is correctly assigned or if the patch has been committed, or
> if there needs to be more work done or not... what is exactly decided here?

I agree. This wrinkle has been around, off and on,
for years. Maybe we should share how we think it
should work using the MCC. I only know how to create
a share using a Mageia(Mandriva/Mandrake) server.
Does the same thing occur with some other Distro
as an NFS server? Like Red Hat or Ubuntu?

i'm just thinking, maybe the original bug is fixed, but it's getting more and more like a feature. perhaps it would be better to close this one and open a newer one which could be clearer and a feature.

(In reply to comment #65)
> i'm just thinking, maybe the original bug is fixed, but it's getting more and
> more like a feature. perhaps it would be better to close this one and open a
> newer one which could be clearer and a feature.

Whatever works. I don't think there is one particular
problem and fix. I think it's multiple issues. One
of which is how the NFS server is set up. I think
we have to say that Mageia, probably 3, is the only
acceptable NFS server and this is the ( only? ) way
that's set up. Once the server is created then a set
of specific steps using the MCC sets up the client.

The MCC presently features the ability to set up
both an NFS Server and a Client. Here is my menu
for setting up a Mageia 2 NFS Server:

For sharing a local directory using NFS
MCC: Network Sharing -> Share drives and directories using NFS
installs nfs-utils
MCC: Share drives and directories using NFS
     Add -> Directory: /home/wilcal/databank
            Access: *
            User ID: No user UID mapping
            Anonymous user ID: (blank)
            Anonymous Group ID: (blank)
            Advanced: all no

---- end menu ----

if anyone has an issue with this please share.

As far as I am concerned the patch I posted in attachment 2475 [details] fixes all the issues with NFS in MCC yet no one has tried it out or even commented on it. The assigned maintainer is completely silent.

If there is something wrong with my fix tell me what it is and propose something better.

(In reply to comment #67)
> As far as I am concerned the patch I posted in attachment 2475 [details] fixes all the
> issues with NFS in MCC yet no one has tried it out or even commented on it. The
> assigned maintainer is completely silent.
> 
> If there is something wrong with my fix tell me what it is and propose
> something better.

@ Derek

Sorry, I didn't read all 67 comments.

The assignee of this bug, Thierry, has done very, very much for Mageia, more than I can understand. Last time I looked he had fixed more bugs than any one else, but unfortunately he has too many assigned to him.

@ AL13N and everyone in the cc of this bug

Did you test the patch? If so, please report whether it fixes this issue for you.

and if you didn't test yet: please test it!

(In reply to comment #67)
> As far as I am concerned the patch I posted in attachment 2475 [details] fixes all the
> issues with NFS in MCC yet no one has tried it out or even commented on it. The
> assigned maintainer is completely silent.
> 
> If there is something wrong with my fix tell me what it is and propose
> something better.

Hi Derek,
I just applied your patch (in mga2 x86_64) and have found my nfs share on another machine on the LAN.

This is the first time *ever* that I have seen that tool work - nice!

Only snag now it that on opening the folder it is displayed as empty. (It's the home folder on my server)

How best to investigate this? 

Barry

CC: (none) => zen25000

Ignore that - a reboot fixed it. \o/

Thanks Derek - excellent WFM :)

I will give it some hard use and report any issues - but I'm sure you did that already ;)

perhaps if it doesn't show regressions we can commit it, if the maintainer still is unresponsive.

(In reply to comment #71)
> I will give it some hard use and report any issues - but I'm sure you did that
> already ;)

To exercise it unmount and delete any existing NFS entry in /etc/fstab first and then try it with and without a firewall, and with and without 'Network Services Autodiscovery' open in the firewall.
In all cases it should find the shares

Any issue with the share once mounted will be down to the NFS options or permissions.

Created attachment 2537 [details]
Updated NFS patch with nmap

Sorry, I just realised I had not uploaded the newest version of the patch.

This version has just one line different. It will avoid searching for nfs shares on VPN interfaces. It will only search the local network.

Attachment 2475 is obsolete: 0 => 1

It has been a long time since I checked that bug report and it becames too long.

First, it would be better to have a series of smaller patches, each self

Then a couple remarks after reviewing your latest patch:

You should run perl_checker on files you're modifying in order to find (and fix) issues in your patches

You're abusing do_pkgs->ensure_binary_is_installed(), it won't install nmap.
You want to use ensure_are_installed() instead. Eg:
...do_pkgs->ensure_files_are_installed([ [ 'nfs-utils-clients', '/sbin/showmount' ], [ 'nmap', '/usr/bin/nmap' ] ]) or ...

You're copying code from network::tools::get_routes().
Duplicating code is wrong, leading to fixing bugs in one side only.
You shoud reuse it instead. eg:
my @routes = network::tools::get_routes()

Could you explain rfc1918() goal? (maybe just a one line comment before or renaming it)
Also, "return 1 if cond" looks better than "if (cond) { return 1 }"
perl_checker should advice you to write "my ($ip) = @_" instead of
"my $ip = shift"

perl_checker would advice you to use foreach instead of for.
Also remove the debug print.
You should keep the same logic as before, aka defaulting $name to '(unknown)' instead of the IP if none.

Also, the "add information to NFS GUI" patch is buggy.
Running perl_checker on smbnfs_gtk.pm should show you "unused variables" and "undeclared ones"

I see the rfc1918() is checking for private ipv4 scope wich might be ok for most, but I know some users use public ip:s behind firewalls too, and it wont work for them...

And if your regional network provider uses private ips within the region, nmap could find a lot of servers :)


But this line I dont like: 
if ( rfc1918($net) and $3 eq '00000000') { push(@hosts,$net."/24") };

Namely the "push(@hosts,$net."/24")" parts wich if I read it correctly assumes everyone uses a /24 mask wich is a very bad assumption..

CC: (none) => tmb

(In reply to comment #75)

>You're copying code from network::tools::get_routes().
>Duplicating code is wrong, leading to fixing bugs in one side only.
>You should reuse it instead. eg:
>my @routes = network::tools::get_routes()

Well spotted, but if in response to Thomas' comment 76 we need to extract the netmask then get_routes() will need to be modified.


>Could you explain rfc1918() goal? (maybe just a one line comment before or
>renaming it)

To avoid running nmap on the public internet it checks for private addressing space.



(In reply to comment #76)
> I see the rfc1918() is checking for private ipv4 scope wich might be ok for
> most, but I know some users use public ip:s behind firewalls too, and it wont
> work for them...
> 
> And if your regional network provider uses private ips within the region, nmap
> could find a lot of servers :)
> 
> 
> But this line I dont like: 
> if ( rfc1918($net) and $3 eq '00000000') { push(@hosts,$net."/24") };
> 
> Namely the "push(@hosts,$net."/24")" parts wich if I read it correctly assumes
> everyone uses a /24 mask wich is a very bad assumption..

nmap needs to be told the subnet to search on. I did not want to run the risk of performing nmap on the public internet so /proc/net/route is searched only for private networks. The $3 eq '00000000' ensures that only directly connected subnets without a gateway are searched so there is no risk of searching the ISPs. I suppose we could leave out the check for private address space and only search on directly connected subnets. 

Yes, I was assuming a 24 bit netmask simply because it almost invariably is, but the netmask can easily be extracted from /proc/net/route

I will take these comments on board and come up with a revision.

For using perl_checker, see /usr/share/doc/perl_checker/perl_checker.html

Created attachment 2779 [details]
Revised nmap patch

Here is a new patch taking into account Comment #75 and Comment #76

The only thing I did not implement was to use the subroutine network::tools::get_routes because it does not return the data in the form I need it. 

get_routes() returns one line per physical interface containing the default route while I need all locally attached subnets.

Attachment 2537 is obsolete: 0 => 1

Comment on attachment 2282 [details]
Patch to add information to NFS GUI

Dialogue patch not needed if nmap is used to search for servers since nmap will work through a firewall

Attachment 2282 is obsolete: 0 => 1

NFS is a LAN protocol, and using a firewall between hosts in a LAN doesn't make much sense, especially for novice users. And if you really need to traverse one, you'd better use NFSv4, the default version nowadays, which relies on port tcp 2049 only.

And the whole idea of using a port scanner to identify available NFS servers on LAN is overbloated. I can't imagine having to mount an NFS share from an unknown server...

CC: (none) => guillomovitch

(In reply to comment #81)
> NFS is a LAN protocol, and using a firewall between hosts in a LAN doesn't make
> much sense, especially for novice users. And if you really need to traverse
> one, you'd better use NFSv4, the default version nowadays, which relies on port
> tcp 2049 only.
> 
> And the whole idea of using a port scanner to identify available NFS servers on
> LAN is overbloated. I can't imagine having to mount an NFS share from an
> unknown server...

Agreed, a firewall is not required between hosts in a LAN, but the default configuration of Mageia is to have the firewall enabled. This is a tool for newbies. Most experienced users would configure NFS by hand. 
Working from behind a firewall is just one of the benefits of this patch. See Comment 60 for a full list, and see Comment 36 for a list of the things wrong with the current tool. (Item 2 in the list is the one that causes the most problems)

As for the idea of scanning for servers. That is what the present tool already does. It just does not work very well.  This patch does not change the functionality of the tool at all. It just fixes a bug.
Using nmap to scan a Class C subnet for NFS puts just 254 packets on the LAN plus a few more for any host that replies. It takes about 10 seconds to complete. The current NFS tool puts fewer packets on the LAN (just 6), but takes over 60 seconds by which time the user has usually given up.

I did take a look at a different method to scan without using nmap. There is a way using IO::Socket::PortState::check_ports but that would take up to 4 minutes to scan a Class C subnet (with 1 second timeout)

I am surprised at how much resistance there is to fixing this bug. This tool has not worked since at least Mandriva 2008. I had imagined people would be pleased there is a fix at last.

Thanks for working on this. Quite honestly, if the patch fixes the time it takes, that is great! I have often just given up as it took too long.

As for setting up NFS through the MCC, it still is broken on my system(s). I have 5 Mageia2 boxes in the house and when I want to connect shares through the MCC, I have to go through the setup, let it write to fstab; but when I try to connect, it doesn't connect. I then have to go in manually into fstab and change all hostnames attached to the shares to 192.168.x.x format rather than the default hostname format.

It just seems weird that this has not been fixed and for such a long time. From my point of view, a user would never be able to establish NFS shares. 

Cheers,

Marc

(In reply to comment #82)

> I am surprised at how much resistance there is to fixing this bug. This tool
> has not worked since at least Mandriva 2008. I had imagined people would be
> pleased there is a fix at last.

+1

I'd rather consider this as a lack of interest rather than a formal opposition. And the whole fact that this tool seems broken since 2008 is than is is actually

CC: guillomovitch => (none)

A main strength of mageia is supposed to be the configuration tools.

I configured NFS manually just because i had to,  but first after wasting time
twice: first messing with the nonfunctional tool and looking it there were
somethign wrong with the server, then reading up on how to do it manually.

I think it is good that the firewall is enabled by default, AND also the NFS
tool should work with it. Most computers here are laptops that occasionally
need to connect to other wifi, and sometimes with a USB internet modem.

NFS is supposed to be the easy network file system on unix systems, right?

The patch in comment 67 works fine for me, in Mageia 2.
The discovering time for servers is shorter. Entry is well mounted directly and also at the boot time.
For example, here is the entry in fstab :
LINUX-AMD-X3.local:/home/yves /mnt/yves nfs rsize=8192,wsize=8192,nosuid,soft 0 0
The name of the server machine is declared in hosts definition.
I think that this version will be much better that the statu quo with a tools which does not work.

CC: (none) => yves.brungard_mageia

I will try the patch but am a little confused as to how to apply it. There are also 2 attachments at the bottom of this page. Would I need to apply both?

Could someone just walk me through how to apply the patch and I will be able to test it against multiple machines here at home. We have 6 Mageia boxes (4 desktops and 2 laptops).

Cheers,

Marc

(In reply to comment #88)
> Could someone just walk me through how to apply the patch and I will be able to
> test it against multiple machines here at home. We have 6 Mageia boxes (4
> desktops and 2 laptops).

Right click the patch titles and 'Save target as' on each.
cd to your download folder (where the patches are)
su
patch /usr/lib/libDrakX/fs/remote/nfs.pm < bug207.patch
patch /usr/sbin/draknfs < patch-draknfs_firewall_warning.txt
exit

I tested using a nfs share on a raspberry-pi (fedora fc17 arm) on my lan.

With the patch it took about 4 seconds to find and all works fine.
This is using Mga2 x86_64 host.

The patch fails to apply on a Cauldron installation.

I also tried to set up a share on my main Cauldron server, but draknfs is totally broken in Cauldron and I don't have time to figure out a manual set-up. (I also can't find a bug report on that issue :\ )

I don't see the firewall warning in draknfs in Mga2. Maybe I didn't look in the right place?

(In reply to comment #90)

> I don't see the firewall warning in draknfs in Mga2. Maybe I didn't look in the
> right place?

Doh! OK, message appears *after* creating the share - it works fine !

This bug is still valid for me in M3A2 on
10/15/12 using boot.iso 10/02/12 32-bit

Concerning my comment 87, I must correct an assertion. The patch I used is the one from comment 79.
Sorry for imprecision.

I am finally getting back to this after some forced time off due to illness. Anyway, I did the patch using the attachments and following Barry's notes (comment 89 -- note that there is a small error in the lines as one of the files does not have the extension .txt, but I did rename the file with the .txt extension). 

So, here are the results:

* My systems are all Mageia2 and all are up to date
* My firewalls on all of my Mageia boxes are turned off
* After doing the patches, I restarted my box
* Then, I used the MCC->Network Sharing->Access NFS drives and directories.
* Diskdrake then crashed and a popupwindow appeared with the following details:

================

The "diskdrake" program has crashed with the following error:

  Can't locate Nmap/Parser.pm in @INC (@INC contains: /usr/lib/libDrakX /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.14.1 /usr/lib/perl5/vendor_perl/5.14.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.0 /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.12.3 /usr/lib/perl5/vendor_perl/5.12.2 /usr/lib/perl5/vendor_perl .) at /usr/lib/libDrakX/fs/remote/nfs.pm line 8.
  BEGIN failed--compilation aborted at /usr/lib/libDrakX/fs/remote/nfs.pm line 8.
  Compilation failed in require at /usr/lib/libDrakX/diskdrake/smbnfs_gtk.pm line 11.
  BEGIN failed--compilation aborted at /usr/lib/libDrakX/diskdrake/smbnfs_gtk.pm line 11.
  Compilation failed in require at /usr/sbin/diskdrake line 117.
  Perl's trace:
  standalone::bug_handler() called from /usr/sbin/diskdrake:117

Used theme: oxygen-gtk

To submit a bug report, click on the report button.  
This will open a web browser window on Bugzilla where you'll find a form to fill in.  The information displayed above will be transferred to that server
It would be very useful to attach to your report the output of the following command: 'lspcidrake -v'.

================

Any ideas as to what I am doing wrong?

Marc

Marc,  You need to install perl-Nmap-Parser

Derek,

Thanks! It works! Is the "perl-Nmap-Parser" needed just for this particular occasion, or was it needed before this? It was not installed on any of my 6 Mageia boxes.

Test tried on laptop, and 2 desktops! This has not worked since Mandriva 2008 ... ahem ... nice to have it back! Great work! It would be even nice if it worked as well on the upcoming Mageia3 release and future releases.

Another comment that I would have is that:

* there should be a point in the install process where the user is asked to name her/his machine. This way, if there are multiple boxes in the same house (such as is the case with me -- 6 Mageia boxes), there would be less confusion with the naming convention of linux-1.local; linux-2.local; linux-3.local ... We should try to avoid a confusing fstab file. To me, the most logical place would be at the point during the install process where the user is asked to type in the root password. There should also be a location in the MCC where a user could easily change the box's name .... I know there is one already, but the wording is simply not clear/simple enough for users to understand ... it should really say something like "Your computer's name:" or "Pick/modify a name for your computer:" or something obvious like this. 

Thanks for this! Will it be patched on a near future update?

Cheers,

Marc

Marc says:
>There should also be a location in the MCC where a
>user could easily change the box's name .... I know there is one already,
Could you were you found it.
I agree with your proposition.

Created attachment 3385 [details]
Improved patch

Here is yet another patch for this bug.

In this version perl-Nmap-Parser is not a requirement. Instead nmap is installed automatically when the GUI starts. The benefit of doing it this way is to reduce bloat by not having nmap as a dependency of drakconf.

To summarise the benefits of this patch.

* It is approx 3 times quicker than the existing tool. (about 20 seconds compared to 1 minute)

* It works even when the local host has a firewall in place.

* It actually works (The existing tool cannot mount shares in most cases)

Attachment 2779 is obsolete: 0 => 1
Attachment 2315 is obsolete: 0 => 1

BTW:  I note in Mageia 3 that nmap is a dependency of system-config-printer, so most users will have it installed anyway.

We should maybe look to get you some SVN access Derek

CC: (none) => eeeemail

Thierry, I'd like to pull this in for beta2 or beta3 at the latest, any objections to this last version in comment 98 ?

Priority: Normal => release_blocker

valid 3beta3

https://forums.mageia.org/en/viewtopic.php?f=15&t=4505

Whiteboard: 3beta2 MGA2TOO => 3beta2 3beta3 MGA2TOO

@thomas:
It should be fixed regarding perl_checker (undeclared variables, unused variables and the like) and yes it can be commited

Commited

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED