Re: odd behaviour of "pwd" & "df" after Live Upgrade?

From: Richard L. Hamilton (Richard.L.Hamilton_at_mindwarp.smart.net)
Date: 08/26/04 

Date: Thu, 26 Aug 2004 01:19:24 -0000

In article <fH2Xc.11551$hY7.9091@newssvr27.news.prodigy.com>,
        Darren Dunham <ddunham@redwood.taos.com> writes:
> In comp.unix.solaris Richard L. Hamilton <Richard.L.Hamilton@mindwarp.smart.net> wrote:
>>>>>> > google% pwd
>>>>>> > pwd: cannot determine current directory!
>>>>>> > google% df -k .
>>>>>> > df: cannot canonicalize .: Permission denied
>>>>>> > google%
>>>>>> > google% cd
>>>>>> > google% pwd
>>>>>> > /export/home/solaris
>>>>>> > google% df -k .
>>>>>> > Filesystem kbytes used avail capacity Mounted on
>>>>>> > /dev/dsk/c0t1d0s7 2992760 1174337 1788496 40% /export/home
>>>>>> > google%
>>>
>>>>> Yep, it's the permissions on the underlying mount point... I would try this:
>>>>>
>>>>> umount /export/home
>>>>> chmod 755 /export/home
>>>>> mount /export/home
>>>>>
>>>>> should take care of the problem....
>>>
>>>> Now wait a minute - I thought underlying mount point permissions only
>>>> were used by certain filesystems (like to provide initial top-level
>>>> permission for tmpfs filesystems). I'm fairly sure they're _not_ used
>>>> by ufs.
>>>
>>> 'used' or 'supposed to be used'?
>>>
>>> I don't know if it's an actual bug or not, but the behavior of
>>> underlying permissions on the mount point causing this kind of problem
>>> has been in UFS for some time.
>
>
>> Seems ok now:
>
>> # mkdir /test_mount
>> # chmod 0100 /test_mount
>> # ls -ld /test_mount
>> d--x------ 2 root other 512 Aug 25 10:56 /test_mount
>> # mount /dev/dsk/c3t0d0s0 /test_mount
>> # ls -ld /test_mount
>> drwxrwxrwx 41 nobody nobody 2048 Dec 2 2003 /test_mount
>> # umount /test_mount
>> # ls -ld /test_mount
>> d--x------ 2 root other 512 Aug 25 10:56 /test_mount
>> # uname -a
>> SunOS mindwarp 5.9 Generic_117171-08 sun4u sparc SUNW,Sun-Blade-100
>
> Does the '#' on your prompt imply that you're root? Permissions issues
> don't usually apply to root.
>
> # ls -ld /mnt/ufs
> d--x------ 2 root other 512 Aug 12 11:38 /mnt/ufs
> # mount /dev/vx/dsk/ufsvol /mnt/ufs
> # ls -ld /mnt/ufs
> drwxr-xr-x 3 root root 512 Aug 12 11:39 /mnt/ufs
> # su - bob
> $ csh
> % pwd
> /tmp
> % pwd
> pwd: cannot determine current directory!
> % ls -ld .
> drwxr-xr-x 3 root root 512 Aug 12 11:39 .
> % ls -la
> ./..: Permission denied
> total 66
> drwxr-xr-x 3 root root 512 Aug 12 11:39 .
> drwx------ 2 root root 8192 Aug 12 11:38 lost+found
> -rw-r--r-- 1 root other 2071648 Aug 12 11:41 quotas

Ok, I use ksh which hides the problem with its built-in pwd. But I can
recreate it if I run /bin/pwd. A truss reveals

3172/1: open("./..", O_RDONLY|O_NDELAY|O_LARGEFILE) Err#13 EACCES

If I had to take a guess, ./.. is being mapped to the ./.. of the
underlying mount point, but the permissions of the underlying ./. are
preventing that from being accessed. Sounds like it would take only
a couple of lines of code (possibly repeated in one or two places) to
fix that one! 

-- 
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil
Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Relevant Pages