Steve Devine wrote: > Another group in our department mounts web folders out of users home afs > space. > I recently moved several thousand user vols from one afs server to > another using vos move. > The folks running the web server reported that several of these > mountpoints were timing out on them. > This has happened before. > I had them run fs flush , flushmount, and flushvolume and still the > timeout continued. Stopping and starting the client fixed it. > So I looked again to make sure that ports 7000~7010 were open on the > fileserver. > They were. Could this be an issue with the clients firewall perhaps? > Seems to me the volserver calls back to the client when something > changes. Is there a recommended port range for afs clients that needed > to be opened for incoming udp traffic? > We are running version 1.4.2 server software. I don't know his client > version but I can find out if needed. > Thanks > /sd
The fileserver contacts the client on the udp port the client contacted the server from. This is typically port 7001/udp. What is the real error that was being reported? The web server might be reporting a timeout but that isn't going to be the real afs error. I would expect that the actual error would have been a VMOVED error from the file server in response to the attempt to read the file using the old FID. The fact that flushing the volume did not help is strange because that forces the server data for the vnode to be removed and forcing a new lookup for the volume. I doubt this is a client firewall issue. A tcpdump of traffic from the client's perspective would be useful as would a "fs examine" and "fs whereis" on the file that cannot be accessed. This output can be compared with the "vos exa" output for the volume. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
