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 <fdru...@uic.edu> wrote:

>
>
> On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <fdru...@uic.edu> 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
>

Reply via email to