I have found the answer to my own problem; the issue was a line in the: /etc/hosts
file like: 127.0.1.1 newserver.math.uic.edu newserver So the AFS server was trying to talk to it's loopback address while external hosts were connecting to the external IP address. Mystery solved! -Fred On Thu, Apr 5, 2018 at 7:15 PM, Fred Drueck <[email protected]> wrote: > > > On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <[email protected]> wrote: > >> Hello other OpenAFS users, >> >> I've recently setup a new file server to try and facilitate upgrading our >> OpenAFS servers to a newer version of debian (the current stable distro: >> stretch). >> >> The server and db server setup seems to have gone smoothly, but I've got >> problems with moving the AFS volumes. >> >> If I try to do a vos move from the old fileserver to the new one, the >> move will fail with: >> >> Failed to move data for the volume 536881885 >> >> VOLSER: Problems encountered in doing the dump ! >> >> However, if I work on the old file server, or another openafs client >> system (in fact, I've got another debian stretch system using the exact >> same version the debian openafs-client package) I can move the volume to >> the new server. >> >> And I can verify by looking at the /vicepc directory that the file is >> there, the vldb says it's there but if I try to move the file back to the >> older server working on the new server it will fail with a message that the >> volume is not found, something like: >> >> The volume 536881885 is not on the specified site. >> The current site is : server newserver.math.uic.edu partition /vicepc >> >> OK ... but that's exactly the arguments I passed to vos as the >> -fromserver and -toserver >> >> And, if I switch over to another openafs-client or the old AFS file >> server I can issue the vos command to move the volume back just fine. >> >> Anybody have any ideas what's going wrong? >> >> -Fred >> > > Looking through the logs, the only thing I saw that looked maybe relevant > was: > > Thu Apr 5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for > volume 536881887 (errno 2). > > but if that's such a problem then why can the other AFS clients happily > manipulate the volume? > > It's puzzling. > > -Fred >
