Windows Offline Files Permissions Problem
I'm having a security problem involving Windows Offline Files. I'm using Offline Files in Windows 10 with files located on a server that is running Windows Storage Server 2008 R2. When connected to the network, my account has no problem accessing files located in appropriate shares on the server. But when my computer is offline, I am unable to access any files that I have not previously accessed on the server while connected online, and receive "Access Denied" messages. The folders that I need to access contain literally millions of files, so I cannot simply take the time to access each of those files in advance while connected online, just so that I will later have the ability to access those same files offline.
Note that I suspect this issue could be related to some recent changed permissions on the server. Here is the relevant setup for one of the accounts with this problem:
On the laptop, there is a local user named Kevin, with a certain password.
On the server, there is an identical user named Kevin with the same password, and that user is a member of the group KAM-BTM.
On the server, the group KAM-BTM has Modify, Read & Execute, Read, and Write permissions on the share containing the files that are exhibiting this problem.
On the server, all subfolders and files beneath the top level share inherit their permissions from the share.
It seems as though the laptop may have cached some obsolete permissions from the server, and the only way those obsolete cached permissions get updated is by directly accessing each individual file while the laptop is connected to the network. Is there any other way to correct these problems? If necessary, I could re-initialize and re-populate the offline files client side cache, but I believe that has already been done since the server permissions were changed, and it failed to correct the problems. I want to avoid doing that again unless it is pretty certain to fix the problems, because there are hundreds of gigabytes of files that need to be available offline, and repopulating the client side cache will all of those files take a great deal of time.
P.S. - I just ran "attrib -r *.* /s" on one of the problem shares, and that did appear to fix this issue for most of the files on that share. However, that is only a partial and somewhat undesirable solution, because 1) it fails to access any hidden files (such as Excel autosave files, for example), and 2) it removes the read-only attribute from any files where that attribute may have actually been intended. Something similar to this command might work, but I need something that merely accesses a file *without* potentially changing anything about it.
Thanks in advance for any help,
Kevin M.
Note that I suspect this issue could be related to some recent changed permissions on the server. Here is the relevant setup for one of the accounts with this problem:
On the laptop, there is a local user named Kevin, with a certain password.
On the server, there is an identical user named Kevin with the same password, and that user is a member of the group KAM-BTM.
On the server, the group KAM-BTM has Modify, Read & Execute, Read, and Write permissions on the share containing the files that are exhibiting this problem.
On the server, all subfolders and files beneath the top level share inherit their permissions from the share.
It seems as though the laptop may have cached some obsolete permissions from the server, and the only way those obsolete cached permissions get updated is by directly accessing each individual file while the laptop is connected to the network. Is there any other way to correct these problems? If necessary, I could re-initialize and re-populate the offline files client side cache, but I believe that has already been done since the server permissions were changed, and it failed to correct the problems. I want to avoid doing that again unless it is pretty certain to fix the problems, because there are hundreds of gigabytes of files that need to be available offline, and repopulating the client side cache will all of those files take a great deal of time.
P.S. - I just ran "attrib -r *.* /s" on one of the problem shares, and that did appear to fix this issue for most of the files on that share. However, that is only a partial and somewhat undesirable solution, because 1) it fails to access any hidden files (such as Excel autosave files, for example), and 2) it removes the read-only attribute from any files where that attribute may have actually been intended. Something similar to this command might work, but I need something that merely accesses a file *without* potentially changing anything about it.
Thanks in advance for any help,
Kevin M.
ASKER
I am NOT using "Work Folders". I am using the older technology "Offline Files", so my statement is exactly correct, not misleading.
The documents in question were not created on the local (client) system while off network. They have been on the server share since long before this client laptop ever started using them.
This is a "workgroup" based network, not active directory.
The only sync method that has ever been used is Windows Sync Center Offline Files sync.
The documents in question were not created on the local (client) system while off network. They have been on the server share since long before this client laptop ever started using them.
This is a "workgroup" based network, not active directory.
The only sync method that has ever been used is Windows Sync Center Offline Files sync.
Is the laptop part of an AD domain? Does the sync center reflect that the file sync up?
If you check directly while in the server whether the file is reflected as being present there?
If you check directly while in the server whether the file is reflected as being present there?
ASKER
No, this is a workgroup based peer to peer network. Yes, Sync Center reports that all files were successfully synchronized with no errors. Yes, the files are verified as being present on the server.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The offlibe files commonly deals with ad member systems and users.
Glad to hear your issue is resolved.
Potentially you would need to reset attributes anytime you create/modify files offlibe.
Glad to hear your issue is resolved.
Potentially you would need to reset attributes anytime you create/modify files offlibe.
Presumably, your setup is possibly to use work folders
Or if you look at the sync server and whether those documents that were created on the local system while off network syncs back to the server share when the system is back within range of the share?
Or are the files in question deals with post reconnect sync through other means and a consequence of which is that the user lacks rights.
The process that handles the replication of the files from the laptop is the server might use other credentials that inudvertantly sets. Security permissions that prevent the user from access.