Unix and Linux network configuration. Multiple network interfaces. Bridged NICs. High-availability network configurations.


Reviews of latest Unix and Linux software. Helpful tips for application support admins. Automating application support.


Disk partitioning, filesystems, directories, and files. Volume management, logical volumes, HA filesystems. Backups and disaster recovery.


Distributed server monitoring. Server performance and capacity planning. Monitoring applications, network status and user activity.

Commands & Shells

Cool Unix shell commands and options. Command-line tools and application. Things every Unix sysadmin needs to know.

Home » Filesystems

Mountpoint permission problem in Solaris

Submitted by on May 4, 2006 – 6:45 pm 2 Comments

The following condition was originally discovered in OpenSolaris 11 (Bug ID: 4697677). This problem occurs when you do mkdir -m 700 on a mountpoint before mounting it. This superceeds whatever permissions you might give to the mountpoint after it’s mounted.

This condition has been known to occur following a Live Upgrade process from Solaris 8 to Solaris 9. Apparently something in the Live Upgrade script sets restrictive permissions on the mountpoint before mounting it. Naturally, the Live Upgrade process is done under root account, so the SysAdmin would never notice the problem.

The symptoms of this issue include problems with the man command for non-root users, which uses nroff, which writes to temporary space in /usr/tmp which is a soft link to ../var/tmp. Also, in the affected filesystem (like /usr) a non-root user can do ls -als and will see something like this:

 2 drwxr-xr-x  47 root     sys         1024 May  4 12:36 .
 2 drwxr-xr-x   2 root     bin         1024 Feb 10 09:36 4lib
 2 lrwxrwxrwx   1 root     other          5 Feb 10 09:23 5bin -> ./bin
 2 lrwxrwxrwx   1 root     root          10 Feb 10 01:03 adm -> ../var/adm

As you may notice, the “..” metalink is missing. Also, you will not be able to access any soft links leading to ../whatever. This may be a big problem for some users and applications.

The easy way of fixing this is, of course, to unmount the filesystem and change the permissions for the underlying mountpoint. However, there is a way of addressing this issue without unmounting anything. The following is a script that would fix the problem using a local NFS mount. It uses /usr/ and /opt as examples.

cd /
mkdir /fix
mkidr -p /fix/mnt
for i in usr opt
        chmod 700 /fix
        share -F nfs -o rw=localhost,root=localhost /
        mount -o vers=3 /fix/mnt
        chmod 755  /fix/mnt/${i}
        umount  /fix/mnt
        unshare /

Print Friendly, PDF & Email


  • Phillip123 says:

    I’m doing a paper for school and I found all my information about Solaris 10 but this. I need to know the number of Clients and Processors it supports. Can anyone give me and answer with a link? Thanks!
    Thank you for your response Patrick. I read all of those pages since my paper was 3 pages of questions. This happened to be the ones I couldn’t find. Also, while Wikipedia is great for Pop Culture questions, it is not a valid source for academia.

  • nyyankees1123 says:

    Is there a struct and/or API on Solaris to determine which drive is currently booted? For example, a Netra 440 can have 4 valid drives, I’d like to know , short of parsing vfstab or prtconf returns, which device is currently booted.


Leave a Reply

%d bloggers like this: