Network share - ghost files appearing in peoples documents

The setup:

I work at a school’s IT support office. We have folder redirection for our users.

The problem:

There is a set of files that appear in my users documents. I don’t know how they are spreading. I had thought that they are in the public desktop folder of some pc. When users would login it would put that on their desktop. I found no evidence of this though. I have logged in to many computers of the school and have not had it happen to my account. Not sure how to get rid of these ghostly files.

Is your site using Roaming Profiles? Is Shadow Copy turned on?
Is the Share a CIFS or NFS share?

Gonna need some more information to help you troubleshoot this one.

We are using folder redirection. The desktops, witch are the ones affected, have local file copy off. They do not store a copy of the users redirected folder on the local machine. The share is smb from a windows server file share. There are no shadow copies. VM’s are backed up at the block level.

Okay. That helps. I forgot what is is called in MS Windows and SMB/CIFS, but do you have delayed write turned on on the share or the system that is acting as your storage mule.

The problem that you describe tends to happen when the delayed write interval is set to long or is set to write as user logoff, machine shutdown. If the users are leaving their systems on or are putting the machines to sleep and are not logging out or shutting down, then file persistence may be your issue.

In the NFS world, delayed write and directory caching is a way to prevent disk thrash on IO laden systems. The caveat is that each user may not see the changes that others make as the buffer lives on the local machine until it gets full or the write event is triggered. CIFS/SMB has a similar feature but unfortunately we use Unix/NFS storage servers here.

I will need to check on the delayed write. I am using the default settings with windows share.

AnnounceComment                 :
AnnounceServer                  : False
AsynchronousCredits             : 512
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 15
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : True
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : False
EnableSMB1Protocol              : False
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                :
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : False
ServerHidden                    : True
Smb2CreditsMax                  : 8192
Smb2CreditsMin                  : 512
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

I am not 100% but that line looks like it should force a write after 10 minutes if the cache has not already been written or flushed.

Maybe you can test this by creating some files on your share under your account, put the system to sleep. Go to another system and see if those files are there. Then delete from the second system, unplug the NIC, and then power up the first system and see what you have left. That should let you know if I have you chasing a red herring or not.