On 6/28/2011 8:15 AM, Michael Richter wrote: >> Do not use Global Drives mounting, it is buggy and does not work. > > We noticed that AFS remembers the submounts but does not show them. So > we have to take a new one everytime. But this is actually the only way > to get full write access to his afs drive.
From the OpenAFS for Windows Release Notes: "3.41. Global Drives (aka Service Drive Letters) are no longer supported by Microsoft The Global DriveAuto-mount feature has been deprecated due to the following Microsoft KB article. http://msdn.microsoft.com/library/en-us/dllproc/base/services_and_redirected_drives.asp "The article says that services mounting drive letters are no longer supported by Microsoft and may act unpredictably. The experience other users have had is that if the connection to the OpenAFS CIFS/SMB server is terminated by the Windows CIFS client, the drive mapping may not be re-established until the machine is rebooted. "OpenAFS supports UNC paths and whenever possible applications should be modified to use UNC form \\AFS\<cellname>\<path> instead of drive letters. "Another problem with service mounted drive letters is that the drives are reported as local disk devices and cannot be resolved as being mapped to the \\AFS name space. As a result, AFS path ioctl operations will fail. The fs.exe and symlink.exe command line tools and the AFS Explorer Shell extension will not operate on service mounted drive letters." In addition, this functionality is going to be removed in 1.7 because the native AFS redirector cannot support it; there are no SMB submounts. Since things work properly on other machines. Perhaps you should focus your attention on determining what is different between this machine and the others. The SysInternals tool set should come in quite handy as will the "fs trace" functionality of the OpenAFS cache manager, and WireShark. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
