petri (Stefan Petri) (09/28/89)
Configuration : Targon/35-M50 with TOS3.2 and NFS3.2 (thats a clone of Pyramid 9810 OSx4.0 , I think) linked via ethernet to some Sun3/60 (SunOs 3.5 and 4.0.3) Today I tried for the first time to import a filesystem via nfs : # mkdir /usr/mnt # mount mplsun:/usr/users /usr/mnt /usr/mnt: not owner -> what does this mean ? # mount /dev/iop/pdisk00a on / type 4.2 (rw,noquota) /dev/iop/pdisk00k on /usr type 4.2 (rw,noquota) /dev/iop/pdisk00l on /u1 type 4.2 (rw,noquota) /dev/iop/pdisk00e on /u2 type 4.2 (rw,noquota) mplsun:/usr/users/mplsun on /usr/mnt type nfs (rw) -> I think, the mount succeeded # ls -a /usr/mnt # -> The ls did'nt even show "." and ".." ! # ls -ld /usr/mnt drwxr-xr-x 14 root 512 Sep 22 13:39 /usr/mnt -> The 14 links are correct for the mounted filesystem. And then : (our root-account is in the att-universe) # ucb ls -aC /usr/mnt . bluemel jabs lost+found schmidt .. broeke klebsch meier tmp bachmann forth linde moeller -> This gives the correct entrys. I wrote some programs to test the stat(2-att), fstat(2-att), stat(2-ucb) and fstat(2-ucb) Systemcalls. They all work on the remote-mounted FS. What doesn't work is the readdir(3X-att) call, opposed to the readdir(3-ucb) call. I think, this kind is of transparency isn't what they call network-transparent- filesystem ? S.P. -- Stefan Petri <petri@tubsibr.UUCP> Technische Universitaet Braunschweig, Institut fuer Betriebssysteme und Rechnerverbund, 3300 Braunschweig, W. Germany.
scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (09/30/89)
In article <1989Sep28.145106.3723@tubsibr.uucp> petri@tubsibr.UUCP (Stefan Petri) writes: >Configuration : Targon/35-M50 with TOS3.2 and NFS3.2 ># ls -a /usr/mnt >-> The ls did'nt even show "." and ".." ! I suggest that you hassle Nixdorf's Tech Support for the fix. If they don't have it, they'll have to get it from Pyramid. It was fixed in a PTF about two years ago; I ran across it about 1-1/2 years back. Perhaps Dave Bloom is out there reading this? I'm sure that he remembers the incident... :-) -- Scott Hazen Mueller| scott@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott 685 Balfour Drive | (408) 298-6213 |Mail to fusion-request@zorch.SF-Bay.ORG San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email
steve@qe2.tcspa.ibm.com (Steve DeJarnett) (09/30/89)
In article <1989Sep28.145106.3723@tubsibr.uucp>, petri (Stefan Petri) writes: > Today I tried for the first time to import a filesystem via nfs : > # mkdir /usr/mnt > # mount mplsun:/usr/users /usr/mnt > /usr/mnt: not owner > -> what does this mean ? I suspect (although I don't know for sure) that it means that the directory is owned by a user-id that doesn't map across NFS (i.e. the directory is probably owned by root on the Sun, which gets shipped across NFS as -2 (or whatever nobody is), which is not the same as the owner of the directory on your Pyramid (probably root). If you change the owner of the directory to nobody, this might go away. In any case, it doesn't cause problems. > # mount > /dev/iop/pdisk00a on / type 4.2 (rw,noquota) > /dev/iop/pdisk00k on /usr type 4.2 (rw,noquota) > /dev/iop/pdisk00l on /u1 type 4.2 (rw,noquota) > /dev/iop/pdisk00e on /u2 type 4.2 (rw,noquota) > mplsun:/usr/users/mplsun on /usr/mnt type nfs (rw) > -> I think, the mount succeeded It must have, otherwise mount would have complained, and the entry wouldn't show up from mount. > # ls -a /usr/mnt > # > -> The ls did'nt even show "." and ".." ! > # ls -ld /usr/mnt > drwxr-xr-x 14 root 512 Sep 22 13:39 /usr/mnt It looks like ls(1-att) doesn't know about NFS (which would make sense, since AT&T supports RFS (they may now have NFS -- I don't really know). When I ran a Pyramid, we did all of our administration on the BSD side, and NFS always worked fine for us. It could be that in keeping the AT&T and the BSD sides separate, Pyramid didn't allow for ls(1-att) to work on NFS filesystems. This seems somewhat strange, but it guarantees that it will behave as the System V ls(1) command is expected to. You might bug your Nixdorf sales critter about the problem. It may have been fixed in OSx 4.4 or 5.0 (I don't know if Nixdorf has a corresponding release of 5.0 yet, but I seem to recall seeing other people saying their Nixdorf OS was equivalent to OSx 4.4 in the past). I don't have access to a Pyramid right now, otherwise I'd check to see if it was fixed in OSx 4.4. Steve DeJarnett IBM Advanced Workstations Division -- Palo Alto ibmsupt!ibmpa!steve@uunet.uu.net or steve@polyslo.calpoly.edu Disclaimer: I speak only for me, etc. In no way do I speak for IBM.