niklas@appli.se (Niklas Hallqvist) (11/03/90)
Hello NFS people! About a month ago I posted the following article: > I have a TCP/IP network with NFS on top of it. Some of the > nodes run Interactive 386/ix 2.0.1 (I think) who acts rather strangely > when I try to set file attributes. If some attributes are unspecified > (e.g uid, gid or mode) they get changed anyway to -1. I know this is > mentioned in the NFS manual for 386/ix. What I'm asking here is not > why this happens, that I understand, but what to do about it. Does > someone know how to patch nfsd or nfs.o? Have someone done a new > version of the RP (remote procedure) which handles the set file attributes > call? Or maybe a RPC filter listening to the original NFS socket, > forwarding some calls to a another port, after reconfiguring nfsd to > listen this new port, and implementing new versions of other RPs. > I'm interested in hints, partial or complete solutions to my problem. I didn't get any answer and I saw no followups either. The fact is: I'm not the only one having this problem, there is at least one other site in Sweden having the same difficulties (but in their case with 386/ix 2.2). I plea, don't pass by this article if you got any ideas of what I can do. Thanks in advance, Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (11/04/90)
The NFS spec says that any element of the "sattr" (settable attributes) structure may be set to -1 if you don't want to change that attribute. Any NFS server which doesn't detect such a value and blindly uses it is clearly broken. I've got a PC running Interactive's stuff in the lab; I'll check it out on Monday. It all seemed to work when I tried it... -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- *** "Now is no time to speculate or hypothecate, but rather a time *** *** for action, or at least not a time to rule it out, though not *** *** necessarily a time to rule it in, either." - George Bush ***
cpcahil@virtech.uucp (Conor P. Cahill) (11/04/90)
In article <1178@appli.se> niklas@appli.se (Niklas Hallqvist) writes: >> when I try to set file attributes. If some attributes are unspecified >> (e.g uid, gid or mode) they get changed anyway to -1. I know this is >> mentioned in the NFS manual for 386/ix. What I'm asking here is not We have had NFS running here for over a year and have not seen this problem. Post a mechanism to reproduce the problem so that others can see what is actually hapening. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
niklas@appli.se (Niklas Hallqvist) (11/04/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <1178@appli.se> niklas@appli.se (Niklas Hallqvist) writes: >>> when I try to set file attributes. If some attributes are unspecified >>> (e.g uid, gid or mode) they get changed anyway to -1. I know this is >>> mentioned in the NFS manual for 386/ix. What I'm asking here is not >We have had NFS running here for over a year and have not seen this problem. >Post a mechanism to reproduce the problem so that others can see what >is actually hapening. Ok, here's an example... I'm running on NCR Tower 650 with UnixV.3 (rel. 030001) and NFS 04.00.00. The current diretory is residing on a machine running 386/ix 2.0.2 and NFS 2.0.0. Example 1, Change of permissions. $ > test1 $ ls -l test1 -rw-r--r-- 1 niklas usr 0 Nov 4 1990 test1 $ chmod 666 test1 $ ls -l test1 -rw-rw-rw- 1 65535 65535 0 Nov 4 1990 test1 Example 2, Change of owning user. $ > test1 $ ls -l test1 -rw-r--r-- 1 niklas usr 0 Nov 4 1990 test1 $ chown root test1 $ ls -l test1 -rwxrwxrwx 1 root usr 0 Nov 4 1990 test1* Example 3, Change of owning group. $ > test1 $ ls -l test1 -rw-r--r-- 1 niklas usr 0 Nov 4 1990 test1 $ chgrp uucp test1 $ ls -l test1 -rwxrwxrwx 1 niklas uucp 0 Nov 4 1990 test1* As you can see, when the permissions bits are changed, the owner and group bits get set to ones. Almost the same thing happens when you change the owning user or group, but then only the permission bits get replaced by one bits. I want to enhance the fact that this only occurs when running on the NCR and using NFS-mounted partitions from a 386/ix node. Not the other way around, or when a 386/ix machine replaces the NCR in my scenario. It just occurred to me, that it really might by the NCR NFS being the bandit here. The question is: How many bits is a NFS attribute? 16 or 32? If it is 32, the problem might be that the NCR just supplies a 16-bit value of -1, which in the 32-bit context surely gets evaluated to 65535. But if the number of bits is 16, I can't see anything but Interactive NFS being guilty! Comments....? I have to know who's responsible if I'm going to report this. Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas
bruce@cs.su.oz (Bruce Janson) (11/04/90)
In article <1180@appli.se> niklas@appli.se (Niklas Hallqvist) writes: >.. >Ok, here's an example... I'm running on NCR Tower 650 with UnixV.3 >(rel. 030001) and NFS 04.00.00. The current diretory is >residing on a machine running 386/ix 2.0.2 and NFS 2.0.0. > >Example 1, Change of permissions. >.. >Example 2, Change of owning user. >.. >Example 3, Change of owning group. >.. >replaced by one bits. I want to enhance the fact that this only occurs >when running on the NCR and using NFS-mounted partitions from a 386/ix >node. Not the other way around, or when a 386/ix machine replaces the >NCR in my scenario. It just occurred to me, that it really might by >the NCR NFS being the bandit here. The question is: How many bits >is a NFS attribute? 16 or 32? If it is 32, the problem might be that >the NCR just supplies a 16-bit value of -1, which in the 32-bit context >surely gets evaluated to 65535. But if the number of bits is 16, I can't >.. Niklas, If it is any consolation we here have experienced similar behaviour between our NFS clients and servers. First it was between MIPS RISC/os 4.0 and SunOS 3.5.2 machines, then it was between MIPS RISC/os 4.0 and MIPS RISC/os 4.5 machines. The mismatch was, as you guessed, in the client v. server interpretation of exactly what constituted a "-1" (i.e. "ignore") value in an nfs_setattr() call. Fortunately we did have MIPS RISC/os 4.0 kernel source (for *almost* all of our MIPS machines) and so could implement a simple fix. I guess it is up to you and your suppliers now to argue over the precise meaning of the NFS spec. and so determine who must change... (Do they both attend the Connectathon?) Cheers, bruce. Bruce Janson Basser Department of Computer Science University of Sydney Sydney, N.S.W., 2006 AUSTRALIA Internet: bruce@basser.cs.su.oz.au Telephone: +61-2-692-3264 Fax: +61-2-692-3838
shirono@ssd.csd.harris.com (Roberto Shironoshita) (11/07/90)
In article <1180@appli.se> niklas@appli.se (Niklas Hallqvist) writes: > cpcahil@virtech.uucp (Conor P. Cahill) writes: > > >In article <1178@appli.se> niklas@appli.se (Niklas Hallqvist) writes: > >>> when I try to set file attributes. If some attributes are unspecified > >>> (e.g uid, gid or mode) they get changed anyway to -1. I know this is > >>> mentioned in the NFS manual for 386/ix. What I'm asking here is not > > >We have had NFS running here for over a year and have not seen this problem. Chances are, all your hosts have the same size attributes (16 bits). > Ok, here's an example... I'm running on NCR Tower 650 with UnixV.3 > (rel. 030001) and NFS 04.00.00. The current diretory is > residing on a machine running 386/ix 2.0.2 and NFS 2.0.0. > > [ Examples deleted ] > > I want to enhance the fact that this only occurs > when running on the NCR and using NFS-mounted partitions from a 386/ix > node. Not the other way around, or when a 386/ix machine replaces the > NCR in my scenario. Someone correct me if I am wrong, but I believe the protocol prescribes 32-bit signed attributes. We saw something quite like this around here. We traced it to the client not properly sign-extending its 16-bit attributes, so it ended up sending 65535 instead of -1. We discovered the problem when one of our machines decided to use 32-bit attributes. Sanity check: how big is the uid field in an inode in Interactive 386/ix 2.0.2? If it is 32 bits, then NCR's NFS 04.00.00 needs a bugfix. -- Roberto Shironoshita || Internet: shirono@ssd.csd.harris.com Harris Corporation || Computer Systems Division || UUCP: ...!uunet!hcx1!shirono || DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.