Autofs fails to update /net with new shares from server

Bug #28380 reported by Jesper Krogh
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
autofs (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Using autofs/automount to mount the NFS shares. Autofs forgets to update /net
with the new exports, As shown below, the showmount -e shows that
the client can fetch the new exportlist from the server but it fails to update
/net.

Server: atlas
Client: sloth

jk@sloth:~$ showmount -e atlas
Export list for atlas:
/z/x3i (everyone)
/z/atlas (everyone)
/z/x3i/vnmr1 (everyone)
jk@sloth:~$ ls /net/atlas/z/
edraid4 x3i
jk@sloth:~$ sudo /etc/init.d/autofs reload
Reloading automounter: checking for changes ...
Reloading automounter map: 6472
Starting automounter: /net.
jk@sloth:~$ ls /net/atlas/z/
edraid4 x3i

Steps to reproduce;

1) Export /share1 from server
2) mount on client using ls /net/server/share1
3) Export /share2 from server.
4) Reload autofs-daemon.
5) See that /net/server/ contains the old information and shomount -e server
gives the correct information.

Matt Zimmerman (mdz)
Changed in autofs:
status: Unconfirmed → Needs Info
Revision history for this message
Jesper Krogh (jesper) wrote :

The problem still persists on edgy

Revision history for this message
Soren Hansen (soren) wrote :

Can you access it? If you 'cd /net/atlas/z/atlas' what happens?

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for autofs (Ubuntu) because there has been no activity for 60 days.]

Revision history for this message
Mathias Gug (mathiaz) wrote :

Reopening.

Changed in autofs:
status: Invalid → Incomplete
Revision history for this message
Jesper Krogh (jesper) wrote :

Søren. No It was not accessible.

Problem easily reproducible on feisty

Revision history for this message
Jesper Krogh (jesper) wrote :

Problem reproducible on gutsy .. according to the autofs-list autofs5 should be used (currently released).

Changed in autofs:
status: Incomplete → New
Mathias Gug (mathiaz)
Changed in autofs:
status: New → Incomplete
Revision history for this message
Jesper Krogh (jesper) wrote : Re: [Bug 28380] Re: Autofs fails to update /net with new shares from server

Hi Mathias.

May I ask why you marked it as incomplete? I'm willing to provide
whatever more information needed, but nothing is asked for in the bug
and the problem is a real PITA when having a large NFS based network.

Jesper

Mathias Gug wrote:
> ** Changed in: autofs (Ubuntu)
> Status: New => Incomplete
>

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

switching back to new...

Changed in autofs (Ubuntu):
status: Incomplete → New
Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

Changed in autofs (Ubuntu):
importance: Medium → Low
status: New → Incomplete
Revision history for this message
Chuck Short (zulcss) wrote :

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Revision history for this message
Chuck Short (zulcss) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in autofs (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Jesper Krogh (jesper) wrote :

It is really dissapointing .. but there has been posted an awfull lot of "automated" crap in this bug, by people who either:

* Didnt read the initial bug or
* Did try out the steps to reproduce

Even though it can be done on any installation, just going ahead using the five points above.

The problem is (AFAIK) reproducible on any version of Ubuntu going from, dapper and up til today, since you still ship autofs4 and not autofs5 as default.

Autofs5 has been released for two years by now.

Sensible answers to this bug would have been stuff like:
* We dont care about autofs, even though we ship it in main
* We cannot reproduce the bug using above steps. (No-one has even claimed that they have tried so far).
.. and a lot of other constructive feedback.

.. I just tried on Karmic and the problem is still there, allthough it might have been slightly better, since the problem is only occouring if someone actively uses the mountpoint.

.. once again (karmic test).

$ sudo apt-get install nfs-kernel-server autofs
$ edit /etc/auto.master and enable /net
$ sudo /etc/init.d/autofs restart
$ mkdir /tmp/test1 /tmp/test2
$ edit /etc/exports and insert "/tmp/test1 *(ro,no_subtree_check)"
$ sudo exportfs -a
$ showmount -e localhost
Export list for localhost:
/tmp/test1 *
$ cd /net/localhost/tmp; ls
test1
$ edit /etc/exports and insert "/tmp/test2 *(ro,no_subtree_check)"
$ sudo exportfs -a
$ sudo /etc/init.d/autofs reload
Reloading automounter: checking for changes ...
Reloading automounter map for: /net
$ ls
test1
$ # Here we should have seen test2 ..
$ ls /net/localhost/tmp/
test1
$ # Here it should have been again.

The fix is to ship autofs5 .. not 4..

4 years, 10 semi-auto generated messages from people systems.. and the fix is even posted in the comments and still no actions.

Jesper

Changed in autofs (Ubuntu):
status: Won't Fix → Confirmed
Revision history for this message
Dave Walker (davewalker) wrote :

Hi Jesper,

I can understand your frustration and no doubt you'll be pleased to know Lucid (10.04) should be shipping 5.0.4, which should mean that this is resolved.

I'm marking this as incomplete, until someone can confirm that they have successfully reproduced this bug on Lucid, running autofs5.

Thanks.

Changed in autofs (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jesper Krogh (jesper) wrote :

Hi Dave

Thank you for finally attending to the bug.

Well since the problem now persists in all "official releases" of Ubuntu as of now, allthough fixed in the current development branch, dont you think it is a bit premature to close the bug. Even as "invalid" since fixed is what you actually are doing.

As far as I know autofs is a part of "main" in all distributions done.

Jesper

Changed in autofs (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Looks like my confirmation has triggered some attention;-)

As far as I can tell autofs5 in Lucid seems to work when restarting the autofs dameon. Just reloading is not enough. But I guess that's a minor issue.

@Jesper: As Lucid will be the next LTS, it kind of supersedes all other distributions. Changes that some of the older releases will have this bug fixed are close to nil. And since bugs are here to track what needs to be done, I would say changing the status to fixed would be okay. Do you agree?

AFAIK Launchpad is able to track the state of a bug in multiple distributions. But I won't try to correctly add all the distribution states as it probably won't help in getting it fixed for older releases;-)

Revision history for this message
Dave Walker (davewalker) wrote :

Hi,

The only supported version of autofs 4 is Hardy:
autofs | 4.1.4+debian-2.1ubuntu1 | hardy

I'm not convinced after this amount of time, it's worth resolving in Hardy. However, marking the main task Fix Released.

Apologies this bug hasn't been handled better over the length of time it has been open.

Thanks.

Changed in autofs (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.