On 11/13/97 12:25:56 you wrote:
Greetings,
We operate an anonymous FTP service using the wuarchive FTP daemon (wu-2.4.2-academ[BETA-13]) on an Alpha running Digital Unix 4.0b. The files are stored on a filer running 4.0.1c.
From time to time we set up anonymous FTP groups, so remote anonymous
users can supply a group password to gain special access to normally inaccessible areas. When the FTP data area was on a local file system on an OSF/1 3.2 system, people could use this group access to upload files onto the FTP server. Now that we have upgraded the OS and moved the data to a filer, attempts to do this result in the error 550 fchown: Not owner.
and a 0-length file on the filer.
Can anybody shed light on why this might be happening?
I ran into a similar problem with BSD/OS doing the same thing. It seems to be like it changes the group first, and then this results in the writes failing when it goes into "normal" permission mode. But it did not occur from a Solaris client. I didn't get a packet trace at the time, so I couldn't figure out if it was a problem with the filer, the OS, or in the way wuftpd is coded. Never tired Digital Unix, but if it's in there, then it is probably worth the time for Netapp to investigate this and determine exactly where the problem lies.
Bruce
On Thu 13 Nov, 1997, sirbruce@ix.netcom.com wrote:
the writes failing when it goes into "normal" permission mode. But it did not occur from a Solaris client. I didn't get a packet trace at the time, so I couldn't figure out if it was a problem with the filer, the OS, or in the way wuftpd is coded. Never tired Digital Unix, but
I've had it happen with SunOS 4.1.x as the client.
I even put in a call to NetApp support about it, asking them if they'd had any prior experience of this happening. (It would seem they didn't recognise the behaviour. Shame.)
What it seemed to be was that if you open a file as one user, and then change user (as wu-ftpd does) some OS's do the wrong thing when it comes to the NFS auth info that they send with each NFS request.
(Someone can step in here and explain which is the correct way that a client should behave. I forget, and I don't have the tcpdump handy that demonstrated it. I could undoubtedly find it if necessary.)
-- jrg.
-
jrg＠demon.net -
sirbruce＠ix.netcom.com