[OpenAFS] 1.3.71 for Windows questions/problems

[Robbie Foust]

Hi,

If I try to navigate directly to \\afs\all\acpub.duke.edu or 
\\afs\acpub.duke.edu then I get an error that says 
"\\afs\all\acpub.duke.edu is not accessible.  You might not have 
permission to use this network resource.  Contact the administrator of 
this server to find out if you have access permissions.    The system 
cannot find message text for message number 0x in the message file for 
\\afs\all\acpub.duke.edu."  (well, except the path represents what I 
tried to access).

If I go to \\afs\all then you are correct, the long cell names are not 
chopped off.  Thanks for that info. :-)

If I run "net use p: \\afs\acpub\users\r\f\rfoust /persistent:no" then I 
get "System error 67 has occurred.  The network name cannot be found."

I don't have any abnormal messages in the event logs.  Just the usual 
"AFS start pending" and "AFS running" messages.  Oh, and if I use a 
forward slash when creating a submount in the AFS client, it converts it 
to a backslash automatically.

I'm having trouble decyphering what the messages in the afsd.log file 
mean so I'll paste a section of it at the bottom of this message 
(hopefully the right section - its a huge file).  If you need more of 
it, let me know.

time 561.654270, pid 364 SMB received op 0xa2 lsn 8
time 561.654280, pid 364 Dispatch (A2)ReceiveNTCreateX vcp[3b42d28] 
lana[3] lsn[8]
time 561.654290, pid 364 NTCreateX for [\_._AFS_IOCTL_._]
time 561.654290, pid 364 NTCreateX da=[2019f] ea=[0] cd=[1] co=[42]
time 561.654300, pid 364 NTCreateX lastNamep=[\_._AFS_IOCTL_._]
time 561.654440, pid 364 NTCreateX Setting up IOCTL on fid[142]
time 561.654450, pid 364 Dispatch return  code[0]
time 561.654630, pid 364 Replacing active_vcp 3b42d28 with 3b42d28
time 561.655440, pid 224 SMB received op 0xb lsn 8
time 561.655450, pid 224 Dispatch (0b)ReceiveCoreWrite vcp[3b42d28] 
lana[3] lsn[8]
time 561.655450, pid 224 smb_ReceiveCoreWrite fid 142, off 0x0, size 0x9
time 561.655530, pid 224 Dispatch return  code[0]
time 561.655920, pid 372 SMB received op 0x2e lsn 8
time 561.655920, pid 372 Dispatch (2e)ReceiveV3ReadX vcp[3b42d28] 
lana[3] lsn[8]
time 561.655930, pid 372 smb_ReceiveV3Read fd 142, off 0x9, size 0x2000
time 561.655940, pid 372 Ioctl uid 1 user 3b42520 name win\rfoust
time 561.655940, pid 372 Ioctl opcode 28
time 561.656850, pid 224 Replacing active_vcp 3b42d28 with 3b42d28


Thanks,

- Robbie



Jeffrey Altman wrote:

> Robbie Foust wrote:
>
>> Hi,
>>
>> We have the 1.3.71 client for windows deployed to several labs on 
>> campus, but are seeing some problems.
>>
>> If I have tokens and go to Start -> Run -> \\afs   then I see a list 
>> of cells such as ".acpub" "acpub" and "acpub.duke.e" but there is no 
>> "du".  Why is it being chopped off?  Also, I can't access the cell 
>> that way.  I get an error that says it isn't accessible.
>
>
> You are browsing the "AFS" SMB/CIFS server.  The OpenAFS SMB/CIFS does 
> not support UNICODE.  Without UNICODE support, SMB/CIFS share names are
> limited to 13 characters.  Hence, all cell names which are longer then
> 13 characters in length will be truncated as reported by a browse 
> operation.
>
> If you wish to browse with full length names, browse  "\\AFS\all" or
> simply type in the full name "\\AFS\cellname".
>
>> That may or may not be related to another issue we're having.  
>> Sometimes we are unable to map drive letters to afs paths.  The user 
>> can get tickets/tokens just fine, but something is breaking 
>> apparently when AFS tries to either find or access the file servers.  
>> The problems are very inconsistant so I've been trying to come up 
>> with a way to explain what we're seeing.
>>
>> It almost seems to be connected to the cache file, but not always.  
>> If we create a "dummy" submount to point to "\afs\acpub", 
>
>
> Submount paths should use forward slashes.  You are mounting to an
> AFS path not a Windows path.
>
>     Drive:    H:
>     Path:     /afs/acpub
>     Submount: dummy
>
>> stop the service, delete the cache file, and restart the service, 
>> then mapping a drive letter (and accessing it) has a much better 
>> chance of working (because it finds the file servers quicker? just 
>> guessing).  If we delete the cache file and reboot the machine, the 
>> drive mapping will probably fail (but then stopping the 
>> service/killing the cache file/starting the service will cause the 
>> drive map to work.  ??).
>
>
> Cache files on Windows are not persistent.  There is no data preserved
> within the cache file and re-used between service stop/start cycles.
>
> What errors are reported to the Windows Application Event Log?
>
> What errors are reported to %WINDIR%\TEMP\afsd.log when you execute
> "fs trace -dump"?
>
> What does NET USE report for the drive mappings?
>
> Jeffrey Altman
>

-- 
Robbie Foust, IT Analyst
OIT - Administrative Information Support
Duke University