Please see the attached screenshot regarding an odd issue where a particular folder within a CIFS share is hidden. The “Emmerson…” folder can only been seen from a windows client when “show hidden files and folders” is selected and “hide protected operation system files” is unchecked. The folder icon is slightly different with the black square in the lower right corner and the attributes are showing RHSAO. When right clicking on the folder I am able to change the read-only and archive attributes but not hidden, it is grayed out. I also tried using SecureShare Access 3.2 but all options are grayed out as well.
The filer is a FAS3040 running ONTAP 7.3P7
Any help is greatly appreciated, I’ve been chasing my tail on this for the last day and a half. Thanks!
We don't Enterprise Vault in our environment and the CIFS share in question isn't touched by any type of backup solution. It's a file repository accessed by our end users via DFS link.
I had this happen once before and it had to do with how the files and folders were copied to the filer. I hope this all makes sense:
I used a program called SecureCopy (similar to robocopy) to transfer files from a server in our San Diego office to a CIFS share on a FAS3160 filer in our data center in Springfield, Ohio. The SecureCopy software itself was installed on a server in our Chicago office where it was configured to run the copy. Every single folder that was copied to the filer was marked hidden with that same icon and the RHSAO attributes. I was able to resolve this by deleting everything on the filer and installing the software and initiating the copy from the San Diego server.
In the case mentioned in the original post the data was copied by a user in the same office as the filer and I don’t have the luxury of deleting this folder and starting over.
FIX: Corrected a behavior where Directory not empty along with Access denied errors could occur when: (a) the Synchronize Target with Source option is selected, and (b) the attributes of the data set to be copied was both Read only and Hidden.
I had a feeling I would confuse the issue with the SecureCopy (v4.11, FYI) example, I apologize for that. That was the only other time I’ve seen this happen when copying data to a CIFS share on one of our filers.
Also, it appears that I was looking a little too deep into this problem… From a command prompt I ran the following command:
attrib -R –H –S -A “\\netappnas01\...\Emerson - Rudd 087886-0108\”
Now the folder is visible but it still has the black icon in the corner and a file attribute of “O”, which apparently stands for offline in NTFS. I’m still not sure as to how this folder became marked like this out of the blue. If I find how to remove the offline attribute and how this happened I will follow up to this thread.
Did you ever get more information on this issue? I'm experiencing the exact same behavior. Also with a NetApp device, also with copying using Secure Copy (5.5.2 in my case). Trying to figure out why it's responding by making the changes to the folder and how to make it go away.
I was not able to resolve the issue using Secure Copy and ended up using robocopy instead. I wish I could be of more assistance but I just gave up troubleshooting what appears to be a software issue. After learning the commands and testing it out a few times I was able to do everything I needed with robocopy.
So we had the same problem using SecureCopy moving from a Windows Files server to CIFS. We used the attrib command from Johns post and it worked like a charm.
attrib -R –H –S -A “\\<Path to folder>”
We still had the offline attribute showing up with the X on certain folders. I looked everywhere hoping this would be an easy point and click. I finally used powershell to remove this offline attribute and it worked like a charm.
$(Get-Item “\\<Path to folder>”).Attributes = ‘Normal’
I did find that the Get-Item cmdlet wouldnt work if the share was hidden which after running the attrib is wasnt. Im sure there are better cmdlets which will change all the attributes including hiddren through powershell. In the end this is what worked for us.