[OpenAFS] OpenAFS installation messes up Windows 8 file access control
Tue, 24 Sep 2013 01:36:53 +0100
Thanks for all the information and hints.
I've upgraded from Windows 8 Standard Edition to Pro, but still had the =
File Explorer bug with OpenAFS. I tried your recipe for disabling the =
OpenAFS device drivers, but that didn't help either. But then I noticed =
(in Sysinternal's Process Explorer) that explorer.exe was loading =
various OpenAFS DLLs even though I had disabled them all in =
Sysinternal's Autoruns. This undermines our earlier elimination of the =
AFS Shell Extensions as possible culprits.
By several long processes of elimination, I found that afs_shl_ext.dll =
was being loaded by a registry key:
which autoruns doesn't know about. If I remove that key, my bug is =
fixed! I checked that this key is added as part of the OpenAFS =
installation and removing it is all that's needed to fix File Explorer's =
administrator access control.
What does this key do? Will it break anything to remove it? I didn't see =
any problem, and the OpenAFS icon overlays and context menus seem to =
> -----Original Message-----
> From: Jeffrey Altman [mailto:firstname.lastname@example.org]
> Sent: 23 September 2013 13:21
> To: Adye, Tim (STFC,RAL,PPD)
> Cc: email@example.com
> Subject: Re: [OpenAFS] OpenAFS installation messes up Windows 8 file
> access control
> On 9/18/2013 8:17 PM, Tim Adye wrote:
> > Hi Jeffrey,
> > Jeffrey Altman <firstname.lastname@example.org> wrote on 16 September
> >> if you are experiencing undesirable behavior on paths located in =
> >> name space then the afs redirectorcan be involved. if the path is
> >> disk or CIFS then the redirector cannot b The Windows Multiple UNC
> >> provider simply will not send those file system operations to the =
> >> file system.
> > Yes, the problem is on my local disk (eg. C:\Program Files). It's =
> the installation of OpenAFS that provokes it.
> An installation of OpenAFS consists of:
> 1. two device drivers
> 2. the three shell extensions in both x86 and x64 variants
> 3. the network provider in both x86 and x64 variants
> 4. the authentication provider
> 5. the service
> 6. the smb pipe service emulators
> >> i can certainly believe that the explorer shell has bugs that are
> >> triggered by the mere existence of a non Microsoft file system. =
> >> explorer shell has a lot of hard coded assumptions that require =
> >> CIFS. this is part of the reason that their new ReFS file system =
> >> supported on client systems.
> > If the installer isn't messing with Explorer's permissions settings,
> then the presence of the OpenAFS IFS does sound like the likely =
> for provoking an Explorer bug. I have installed some other IFS systems =
> my machine, but it looks like only OpenAFS causes the problem.
> what other IFSs have you installed? Are they network file systems? =
> they provide all of the system components that OpenAFS provides?
> > Can I test this by uninstalling or disabling the OpenAFS IFS alone? =
> can switch off all the OpenAFS programs (with autoruns and the =
> control panel), but the problem remains. It takes a full OpenAFS =
> to cure it. It would narrow down the problem if I can disable or =
> just the IFS and check if that is the crucial step.
> The device drivers can be disabled in the registry
> The "Start" parameter determines whether or not (and when) the driver =
> loaded. A value of "4" disables the device driver. The service will
> switch to SMB mode if the drivers are not available. SMB mode =
> the "microsoft loopback" adapter be installed.
> The service is
> >> it is also possible that another file system filter installed on =
> >> machine is altering the return code which prevents user account =
> >> from be triggered. however, it sounds like the real problem is =
> >> the explorer shell thinks the volume you are working on is readonly =
> >> therefore decides to hide the UI controls.
> > The symptoms are a little different from a read-only device. For
> example, the delete button is not greyed out, and attempting to delete =
> file still brings up the "are you sure you want to move this to the
> recycle bin" prompt (if delete prompts are enabled) before silently
> failing. I just checked with a read-only SD card and the behaviour is
> different there.
> What are the differences in behavior as viewed by SysInternals Process
> >> this would be an explorer shell bug which must be addressed by
> > That does seem likely, but how to get them to do so? Tracking down a
> more specific cause would probably help. I don't know the best =
> to report a Windows bug.
> Reporting bugs to Microsoft requires a Professional Support Contract =
> the operating system in question or payment for a support incident.
> > If it's not some combination of things on my specific system, then
> everyone who installs OpenAFS on Windows 8 (64 bit? Standard Edition?)
> will hit this really annoying problem. Is it just me? Does anyone else
> here see it? I was "lucky" to spot that it appeared when I installed
> OpenAFS; many people might not. I'm planning on upgrading to Windows 8
> Pro, so I hope soon to see if the issue is specific to the Standard
> None of YFSI's support customers have complained about this behavior.
> That being said, none of our support customers are deploying Windows 8
> in a production end user environment.
> > Thanks,
> > Tim.
> >> Jeffrey Altman
> >> On 9/15/2013 10:03 PM, Tim Adye wrote:
> >>> Hi Jeffrey,
> >>> Thanks for the information.
> >>>> The only interaction between OpenAFS and the Explorer Shell is =
> >>>> Shell Extension" which provides the "AFS Context Menu", the "AFS
> >>>> Property Sheets", and "Mount Point and Symlink Overlay Icons". =
> >>>> the functionality you would have disabled using "autoruns".
> >>> Yes, I tried disabling all of those, but that didn't help.
> >>> If, as you suggest, it isn't OpenAFS running, then there must be
> >> something that the OpenAFS installer and uninstaller do to affect
> >> Explorer. I installed and uninstalled OpenAFS many times (often =
> >> other action except for the reboot) and the problematic behaviour I
> >> described appeared if, and only if, OpenAFS was installed (whether
> >> or not).
> >>> Could there be some local policy or groups that are changed by the
> >> installer? I know that it adds the "AFS Client Admins" group, =
> >> can't be it as the uninstaller doesn't remove the group.
> >>> Thanks,
> >>> Tim.
> >>> -----Original Message-----
> >>> From: Jeffrey Altman [mailto:email@example.com]
> >>> Sent: 15 September 2013 23:35
> >>> To: Adye, Tim (STFC,RAL,PPD)
> >>> Cc: firstname.lastname@example.org
> >>> Subject: Re: [OpenAFS] OpenAFS installation messes up Windows 8 =
> >> access control
> >>> Tim,
> >>> I'm sorry you are experiencing a problem but the reason you didn't
> >>> any changes that were made by OpenAFS is because OpenAFS doesn't =
> >>> any changes.
> >>> The only interaction between OpenAFS and the Explorer Shell is the
> >>> Shell Extension" which provides the "AFS Context Menu", the "AFS
> >>> Property Sheets", and "Mount Point and Symlink Overlay Icons". =
> >>> the functionality you would have disabled using "autoruns".
> >>> Jeffrey Altman
> >>> On 9/15/2013 4:08 PM, Tim Adye wrote:
> >>>> Hi,
> >>>> The OpenAFS client installation is doing something nasty to the =
> >> access
> >>>> control on my Windows 8 system. After installing OpenAFS, I can =
> >> longer
> >>>> move, copy, or delete files with the File Explorer in local =
> >> folders
> >>>> that require administrator privileges.
> >>>> What should happen, and happens again if I uninstall OpenAFS, is =
> >> get
> >>>> a pop-up message such as "File Access Denied: You'll need to =
> >>>> administrator permission to copy to this folder". I can then then
> >> select
> >>>> "Continue" (perhaps needing an admin password) to copy the file.
> >>>> When OpenAFS is installed, there is no pop-up message and the =
> >> silently
> >>>> fails. This occurs with drag-and-drop and Ctrl/C+X+V copy and =
> >>>> deleting with the "Delete" key or button. Oddly, the pop-up =
> >> does
> >>>> appear when creating or renaming a file or folder, so those
> >> still
> >>>> work. It is also possible to delete files from the context menu
> >> show
> >>>> the admin icon and don't normally require confirmation).
> >>>> This is a problem with Windows Explorer (now called File Explorer =
> >> Windows
> >>>> 8) and seemingly nothing to do with OpenAFS, except that it =
> >> whenever
> >>>> OpenAFS is installed. I can fix the problem by uninstalling =
> >> and the
> >>>> problem comes back when I reinstall OpenAFS. I tried disabling =
> >>>> OpenAFS components with "autoruns" (and restarting), but the =
> >>>> remained. So I guess it is some change made by the OpenAFS
> >>>> program. What changes does it make to the Windows Account Control =
> >>>> authorisation systems that might cause such an issue? I tried
> >>>> registry dumps before and after uninstalling OpenAFS, but didn't =
> >>>> anything obvious.
> >>>> I used the standard OpenAFS IFS install and all the default =
> >> (all
> >>>> enabled, except integrated login), but it didn't help to disable =
> >> rest.
> >>>> I am using 64-bit Windows 8 Standard Edition (so I can't check =
> >> or
> >>>> group policy changes, since that control panel requires Windows 8
> >> I
> >>>> installed 64-bit OpenAFS 1.7.2600, but had the same problem with =
> >> older
> >>>> version, 1.7.0800, that does not give me this problem on a =
> >> Pro
> >>>> system. So, it could be Windows 8 (vs 7) or Standard Edition (vs
> >>>> Does anyone have any ideas? I would be very grateful for any fix =
> >>>> work-around. With OpenAFS installed, it is extremely cumbersome =
> >> any
> >>>> program file changes on my system. The only way I have to copy or
> >>>> program files in Windows Explorer is by taking ownership and =
> >> the
> >>>> permissions on all directories and files involved, making the =
> >>>> restoring the original permissions - a cumbersome and risky
> >> Or
> >>>> else to do everything from the command-line from an Admin =
> >>>> Thanks,
> >>>> Tim.
> >>>> =
=3D=3D cut here =
> >>>> Tim Adye T.J.Adye@rl.ac.uk =
> >>>> ATLAS Group, Particle Physics Dept, Rutherford Appleton Lab
Scanned by iCritical.