The auto.net script that comes with autofs is broken

Bug #111612 reported by Paul Smith
8
Affects Status Importance Assigned to Milestone
autofs (Ubuntu)
Fix Released
Undecided
Kees Cook

Bug Description

Binary package hint: autofs

The /etc/auto.net script that comes with the autofs package breaks if the server exports filesystems with different permissions to different clients, which is an extremely common thing to do in an enterprise environment. With the existing autofs version of auto.net, the /net map simply doesn't work in this configuration. Consider the following output:

# /sbin/showmount --no-headers -e nfs-server
/tools *
/tools adminclient

This happens because the server is configured to export the filesystem with different permissions depending on the client; for example in a common situation the "adminclient" would have root privileges on the filesystem while the other clients (matching "*") would not.

The /etc/auto.net script parses this up into output that automount wants, as follows:

# /etc/auto.net nfs-server
-fstype=nfs,hard,intr,nodev,nosuid,nonstrict,async \
        /tools nfs-server:/tools \
        /tools nfs-server:/tools

This doesn't work, though, because there are two entries for that mount point and automount just ignores them both (I suppose):

# ls /net/nfs-server/tools/.
ls: /net/nfs-server/tools/.: No such file or directory

It looks to me like the script *tries* to get rid of duplicates by running through sort -u -k1, but that's obviously not enough; even though the first key is identical, sort doesn't omit lines unless the entire line is duplicated not just the key (even if you give -k1). I believe that what you want is to use cut first to grab just the first item, then sort -u, like this:

$SHOWMOUNT | LC_ALL=C cut -d\ -f1 | LC_ALL=C sort -u \

After I make this change to /etc/auto.net and restart, my /net map for this system works properly.

Tags: autofs mount nfs
Revision history for this message
Paul Smith (psmith-gnu) wrote :
Revision history for this message
Paul Smith (psmith-gnu) wrote :

This is still broken in Hardy.

It doesn't seem like anyone is looking at autofs bugs for Ubuntu. Does anyone actually maintain this package?

Morten Kjeldgaard (mok0)
Changed in autofs:
assignee: nobody → mok0
status: New → In Progress
Revision history for this message
Morten Kjeldgaard (mok0) wrote :

I agree that this is indeed a bug, and that the fix suggested by Paul is reasonable. There is no regression with the addition; with the suggested modification, /etc/auto.net still works for me.

Attached please find a debdiff that implements the fix as another dpatch.

Changed in autofs:
assignee: mok0 → nobody
status: In Progress → Confirmed
Revision history for this message
Daniel Holbach (dholbach) wrote :

Kees: can you please take a look at it?

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

This bug was fixed in the package autofs - 4.1.4+debian-2.1ubuntu1

---------------
autofs (4.1.4+debian-2.1ubuntu1) hardy; urgency=low

  * Fixed auto.net to deal with cases where a host exports the
    same directory several times (with different options, for example).
    The patch was added to debain/patches (LP: #111612).
  * Ubuntu core maintainer munge.

 -- Morten Kjeldgaard <email address hidden> Wed, 09 Apr 2008 16:47:39 +0200

Changed in autofs:
status: Confirmed → Fix Released
Kees Cook (kees)
Changed in autofs:
assignee: nobody → keescook
Revision history for this message
Paul Smith (psmith-gnu) wrote :

This bug is NOT fixed. Please reopen it. After installing, I still have exactly the same broken behavior as before, and when I look in /etc/auto.net I see it is still using sort -k, not sort -u:

        $SHOWMOUNT | LC_ALL=C cut -d' ' -f1 | LC_ALL=C sort -k 1 | \

Looking at the debdiff attached to this bug I can see that that still uses -k as well, not -u, and looking at the /usr/share/autofs/conffiles/auto.net file on my system after installing this update it also uses -k instead of -u.

It seems that when my patch was applied, only the part that uses cut was applied, but NOT the part that uses -u instead of -k to sort.

There doesn't seem to be any way to fail a bug resolution so hopefully someone is still reading these...

Cheers!

Kees Cook (kees)
Changed in autofs:
status: Fix Released → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package autofs - 4.1.4+debian-2.1ubuntu2

---------------
autofs (4.1.4+debian-2.1ubuntu2) intrepid; urgency=low

  * Fix auto.net to use "sort -u", which was missing in the fix for solving
    LP: #111612.

 -- Kees Cook <email address hidden> Wed, 28 May 2008 17:33:48 -0700

Changed in autofs:
status: Fix Committed → Fix Released
Revision history for this message
Paul Smith (psmith-gnu) wrote :

That looks better; thanks!

Revision history for this message
yoyoq (yoyoq) wrote :

the default synaptic package is still the broken one
4.1.4+debian-2.1ubuntu1
as of July 10, 2008

although i think i have other problems

Revision history for this message
Paul Smith (psmith-gnu) wrote :

Ouch; yoyoq is right. The new version 4.1.4+debian-2.1ubuntu2 is in the pool, but it's not listed in any of the hardy Packages file; I've looked in all of them (hardy, hardy-proposed, hardy-backports, hardy-security).

I didn't notice this because I pulled the .deb and installed it by hand to test it out, but on another system that is up-to-date if I start Synaptic I see that autofs-4.1.4+debian-2.1ubuntu1 is the latest and only version available.

Somehow, ubuntu2 didn't get added to the packaging files even though it did build correctly. Odd...?

Can someone please check this out?

Changed in autofs:
status: Fix Released → In Progress
Revision history for this message
Kees Cook (kees) wrote :

Correct, this is fixed in Intrepid (not in Hardy). Since the problem is small, it isn't planned to be backported to Hardy.

Changed in autofs:
status: In Progress → Fix Released
Revision history for this message
Paul Smith (psmith-gnu) wrote :

I don't agree that the problem is small.

The FIX is small, but the problem is big: it basically means that the /net map is completely unusable in Hardy, for any environment where filesystems are exported with different permissions to different sets of hosts.

As I mentioned above, this is an extremely common situation in Enterprise environments where you have dedicated fileservers/NAS boxes: you typically export them without root squash to one box, for managing the content (since you don't want to log into the NAS box to do it), and WITH root squash everywhere else (to ensure root-owned files are not overwritable by any random client).

Since Hardy is an LTS release one would assume that it would be particularly recommended for Enterprise environments and more sensitive to these sorts of bugs than a "normal" Ubuntu release.

Revision history for this message
Kees Cook (kees) wrote : Re: [Bug 111612] Re: The auto.net script that comes with autofs is broken

On Mon, Jul 21, 2008 at 06:54:50PM -0000, Paul Smith wrote:
> Since Hardy is an LTS release one would assume that it would be
> particularly recommended for Enterprise environments and more sensitive
> to these sorts of bugs than a "normal" Ubuntu release.

If the ubuntu-sru team can be convinced to take it as an SRU, please feel
free to follow the process outlined here:
https://wiki.ubuntu.com/StableReleaseUpdates

Revision history for this message
yoyoq (yoyoq) wrote :

i would have to agree its not small.
essentially this causes autofs to fail.

Revision history for this message
oligau2000 (oligau2000) wrote :

I agree, I user Ubuntu Feisty and switched to Hardy lately and this bug came to me as a non-sense.
I'm also having trouble with Nautilus and authicated Samba shares.
Things like that, that used to work well, should not be broken in the latest release.

Revision history for this message
Paul Smith (psmith-gnu) wrote :

Strange, I've had many bugs fixed in hardy going through -proposed and then into -updates and I've never needed to use the SRU process before. However, if you think it's necessary I'll give it a shot.

Revision history for this message
yoyoq (yoyoq) wrote :

would anyone recomend afuse or amd as a more stable alternative
to autofs?

Revision history for this message
oligau2000 (oligau2000) wrote :

I just want to bump this, as I tried the package 4.1.4+debian-2.1ubuntu2 by manually installing it on my Hardy installation (using Ubuntu Studio 8.04) and it doesn't fix my problem to use autofs /net.
I also tried to use the defaut hardy autofs package and patch /etc/auto.net file manually then restart autofs, but it yelled the same result.
The package/patch/bug needs to be revised and backported to hardy and proposed as a SRU.
This is a major funbreaker when you upgrade to hardy.

Revision history for this message
Paul Smith (psmith-gnu) wrote :

FYI, just discovered that the fix made here for autofs4 was never applied to autofs5, and the same bug exists there; filed:

https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/912030

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.