Thanks for your response. My experience is, in general, that even long-idle AFS mounts work fine across NAT; the only time this has caused a problem is when there's a documented drop in connectivity between the firewall and the AFS server.
I'll work on fs checks and fs flush next time this happens. As much as I like AFS, I'm impressed that it's really the only reason I ever have to reboot my machine -- /etc/init.d/openafs-client restart doesn't work, nor does stop, nor does umount /afs. That seems like a flaw in the implementation -- it ought to be possible to stop and restart the service without a reboot! Thanks for the nitpick - just reminds me that I don't really understand the technology I'm using.... ap ---------------------------------------------------------------------- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu On Thu, 23 Jan 2003, David Z Maze wrote: > Andrew Perrin <[EMAIL PROTECTED]> writes: > > I'm running debian woody on a home machine that's behind an NAT > > masquerader (also woody). The home machine runs the OpenAFS client > > to connect to the UNC campus's AFS shared directory space. Generally > > this works fine, but there's one situation that consistently causes > > a problem. > > What I've been told around here is that AFS over a NAT will maybe > probably work, if you don't have too much load and don't let it sit > idle too long, and that you can vaguely expect to lose randomly. > > > The scenario is this: > > 1.) Cable modem service dies while a file in the AFS space is open > > (usually a perl or latex file in emacs). > > 2.) Cable modem service returns, and IP connectivity is fine (including to > > the AFS server).. BUT > > 3.) attempting to access files and directories in the AFS space results in > > "no such file or directory." > > At this point, you might try running 'fs checks' to see if your local > AFS client believes the world exists. Variations on 'fs flush .' > might help too. > > > 4.) tokens reports appropriate kerberos tokens for the user > > 5.) klog lets me create new tokens seamlessly, but none of this allows for > > actually accessing the AFS space. > > Being nitpicky, Kerberos tickets, AFS tokens. :-) If your site > doesn't use kaserver (UNC it appears does) but you do use krb5, you > need to remember to get addressless tickets with 'kinit -A' before > getting tokens using aklog. But this doesn't actually apply to you. > > > 6.) I can umount /afs (as root) but can't remount it. If I try > > /etc/init.d/openafs-client start, I get "I/O error." If I try restart, > > the system hangs completely, requiring a cold reboot (power cycle). > > Stopping and restarting the AFS subsystem has never worked well for > me. I'd never try to just unmount /afs, always run > /etc/init.d/openafs-client stop, but there's no guarantee that it'll > happily restart without a reboot. :-( > > -- > David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ > "Theoretical politics is interesting. Politicking should be illegal." > -- Abra Mitchell > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
