Skip to content

Fixing a covered mount point

September 16, 2005

What do you do when the permissions on your mount point are wrong? I got asked this today as one of my colleagues was trying to recover from bug 4992478. I was slightly surprised that everyone who has ever done SunOS system admin did not know this.

The whole symptoms of this are bizarre. Users can’t do things that they should be able to do: eg:

Sun Microsystems Inc.   SunOS 5.11      snv_21  October 2007
: v4u-4000d-gmp03.eu TS 1 $; cat /etc/nodename
v4u-4000d-gmp03
: v4u-4000d-gmp03.eu TS 2 $; cat /foo/../etc/nodename
cat: cannot open /foo/../etc/nodename
: v4u-4000d-gmp03.eu TS 3 $; ls -la /foo
/foo/..: Permission denied
total 18
drwxr-xr-x   3 root     root         512 Sep 16 12:36 .
drwx------   2 root     root        8192 Sep 16 12:36 lost+found
: v4u-4000d-gmp03.eu TS 4 $;

This came about because I did this when I mounted the file system:

v4u-4000d-gmp03 393 # mkdir -m 700 /foo
v4u-4000d-gmp03 394 # mount /dev/dsk/c3t1d0s2 /foo
v4u-4000d-gmp03 395 #

The permissions on the directory that is being covered by the mount point are to restrictive. So how can you fix that? Clearly unmounting “/foo” and then doing “chmod 755 /foo” would do it but what if you can’t unmount the file system?

Here is one way, without resorting to fsdb:

v4u-4000d-gmp03 503 # share -F nfs -o rw=localhost,root=localhost /
v4u-4000d-gmp03 504 # mount -o vers=3 127.0.0.1:/ /fix/mnt
v4u-4000d-gmp03 505 # chmod 755  /fix/mnt/foo
v4u-4000d-gmp03 506 # chmod 700  /fix/mnt/foo
v4u-4000d-gmp03 507 # umount  /fix/mnt
v4u-4000d-gmp03 508 # rmdir -p  /fix/mnt
v4u-4000d-gmp03 509 # mkdir -p  /fix/mnt
v4u-4000d-gmp03 510 # chmod 700 /fix
v4u-4000d-gmp03 511 # share -F nfs -o rw=localhost,root=localhost /
v4u-4000d-gmp03 512 # mount -o vers=3 127.0.0.1:/ /fix/mnt
v4u-4000d-gmp03 513 # chmod 755  /fix/mnt/foo
v4u-4000d-gmp03 514 # umount  /fix/mnt
v4u-4000d-gmp03 515 # unshare /
v4u-4000d-gmp03 516 #

and now all is well for the users:

: v4u-4000d-gmp03.eu TS 4 $;  ls -la /foo
total 20
drwxr-xr-x   3 root     root         512 Sep 16 12:36 .
drwxr-xr-x  32 root     root        1024 Sep 16 13:47 ..
drwx------   2 root     root        8192 Sep 16 12:36 lost+found
: v4u-4000d-gmp03.eu TS 5 $; cat /foo/../etc/nodename
v4u-4000d-gmp03
: v4u-4000d-gmp03.eu TS 6 $;

 

Obviously we are playing fast an loose with nfs as we all know that you should not do local NFS mounts, so the proper way would be to use another system to act as the client, but the risk is small and made smaller by me making “/fix” mode 700, although there is a race in the order I ran the above commands, but hey this is a blog not a text book.

 

One odd thing is that this does not work “out of the box” with NFS v4, need to think about that one.

 

Tags: topic:[solaris] topic:[SunOS] topic:[UNIX] topic:[NFS] topic:[sysadmin]

Advertisements

From → Solaris

7 Comments
  1. It has just been pointed out that I have included more commands that are actually needed.

    The complete list starts at command 509 in the example. The earlier commands were me breaking it again so I could fix it.

  2. David Cole permalink

    I think that NFSv4 can’t be used to recover from a covered mount point due to the new file-system namespace feature.
    The NFSv4 server understands that /var is a separate, mounted file system in a way that NFSv3 does not. Even though /var is not exported it uses the permissions of the /var file-system rather than the permission of the directory, presumably in preparation for you sharing & using it.

  3. Jean-Marc Gillet permalink

    “I was slightly surprised that everyone who has ever done SunOS system admin did not know this.”
    Well, the rest of us don’t think of it immediately : you cannot share a non-local file system. So the mount point is inevitably unmasked.
    Thanks for your solution. It worked.

  4. Actually it is not that you can’t share a non-local file system that makes this work. It is because shares of local file system don’t cross mount points.
    Glad it helped.

  5. Hans J. Albertsson permalink

    I would agree with DC, it’s not something you’d think of right away, no matter how SA savvy you are.
    I do remember in BSD days, you’d climb down the original inode’s pointers, and for small dirs, you could identify if it had been empty or not.
    That would be the "resorting to fsdb" trick, today.
    Still, thanks!
    And, you can chide us all you want, as long as you get us where we need to be in the process.

  6. Hans J. Albertsson permalink

    It was JMG I agreed with. Sorry. DC probably thought of it immediately.

  7. Mike Gerdts permalink

    You can do this without NFS as well…

    First, we reproduce the problem config…

    # mkdir /var/tmp/a
    # chmod 700 /var/tmp/a
    # lofiadm -a ~mgerdts/iso/sol-10-u9-ga-x86-dvd.iso
    # mount -F hsfs -o ro /dev/lofi/1 /var/tmp/a

    This is the fix procedure.

    # mkdir /var/tmp/fix
    # mount -F lofs -o nosub / /var/tmp/fix
    # chmod 755 /var/tmp/fix/var/tmp/a
    # umount /var/tmp/fix
    # rmdir /var/tmp/fix

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: