I ended up unjoining the client laptop from the homegroup and then rejoining it. After doing this, the permissions prompt went away, and I was able to browse again, and Offline Files began behaving normally. So, my conclusion is that this was a permissions issue pertaining to the fact that I had recently done a bunch of driver updates on the target computer, including extensive updates to the network adapters, and had also added the Intel Wireless Display and MyWiFi software. Homegroup was the cultprit. After unjoining and rejoining all my computers to the homegroup, everything seems to be working again.

# see http://msdn2.microsoft.com/en-us/library/bb201634.aspx
#
# *NdisDeviceType
#
# The type of the device. The default value is zero, which indicates a standard
# networking device that connects to a network.
#
# Set *NdisDeviceType to NDIS_DEVICE_TYPE_ENDPOINT (1) if this device is an
# endpoint device and is not a true network interface that connects to a network.
# For example, you must specify NDIS_DEVICE_TYPE_ENDPOINT for devices such as
# smart phones that use a networking infrastructure to communicate to the local
# computer system but do not provide connectivity to an external network.
#
# Usage: run in an elevated shell (vista/longhorn) or as adminstrator (xp/2003).
#
# PS> .\fix-vmnet-adapters.ps1

# boilerplate elevation check

$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = new-object Security.Principal.WindowsPrincipal $identity
$elevated = $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)  

if (-not $elevated) {
    $error = "Sorry, you need to run this script"
    if ([System.Environment]::OSVersion.Version.Major -gt 5) {
        $error += " in an elevated shell."
    } else {
        $error += " as Administrator."
    }
    throw $error
}

function confirm {
$host.ui.PromptForChoice("Continue", "Process adapter?",
[Management.Automation.Host.ChoiceDescription[]]@("&No", "&Yes"), 0) -eq $true
}

# adapters key
pushd 'hklm:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}' 

# ignore and continue on error
dir -ea 0  | % {
    $node = $_.pspath
    $desc = gp $node -name driverdesc
    if ($desc.driverdesc -like "virtualbox*adapter") {
        write-host ("Found adapter: {0} " -f $desc.driverdesc)
        if (confirm) {
new-itemproperty $node -name '*NdisDeviceType' -propertytype dword -value 1
        }
    }
}
popd

# disable/enable network adapters
gwmi win32_networkadapter | ? {$_.name -like "virtualbox*adapter" } | % {

# disable
    write-host -nonew "Disabling $($_.name) ... "
    $result = $_.Disable()
    if ($result.ReturnValue -eq -0) { write-host " success." } else { write-host " failed." }
    # enable
    write-host -nonew "Enabling $($_.name) ... "
    $result = $_.Enable()
    if ($result.ReturnValue -eq -0) { write-host " success." } else { write-host " failed." }
}

Here’s the problem. When you use offline files in Windows, it creates a cache of everything that’s available offline, in C:\Windows\CSC. Sometimes stuff gets all kludged up for some reason and you start getting all kinds of sync errors. This happens to me once a year or so. It’s a pain, but the convenience and security of offline files makes it worthwhile to me. So, to fix this, you need to empty the cache, but ne touchez pas this directory! Instead, you have to delete it another way. In prior versions of Windows, you could go to offline files and CTRL-SHIFT click on “Delete files”, and it would purge your cache (or something like that…I forget what you were supposed to do). In Windows 7, they made this harder, for whatever rush-to-retail reasons they had in mind. You have to add the following registry entry and then reboot your computer:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CSC\Parameters]
“FormatDatabase”=dword:00000001

After you reboot, Offline Files should find the key and start clearing your cache. When it’s empty, you can resync all your folders.