I experienced an issue recently where my user account which is in the builtin adminstrators group on the SVM was unable to view permissions in a folder via a CIFS share, nor was it able to take ownership. Typically in this situation, I can go in as my user account and because it is in the builtin adminstrators group, it has the ability to take ownership which will then allow me to modify permissions and access the data. However, in this particular instance, I wasn't able to modify permissions nor access the data until a lock was cleared using the "vserver locks" command class. The particular type of lock that was on the folder prior to me regaining access (after I cleared the lock) was a "read-deny_none" lock as was shown in the output of the "vserver locks show" command.
When troubleshooting the issue, I leveraged the "vserver secuirty file-directory" command class and run a task that reported that my user account took ownership of the file when viewing the permissions using this same command class, but then if I attempted to view the permissions via Windows I still received permission denied. I also took a gander at the secd logs for the node but nothing jumped out at me.
Once the issue was resolved (by clearing the lock) I then attempted to reproduce the error by having another user open a connection to the share so that the same "read-deny_none" lock was reported, but I was able to successfully take ownership of the folder with my account in the builtin administrators group and did not need to remove the lock. I even tried having a user actively write data (to create an op-lock) into the folder while I attempted to take ownership of the folder, and it again was successful.
In researching this issue online I found this forum https://community.spiceworks.com/topic/315441-unable-to-take-ownership-of-files-in-win-2k8-r2-server which talks about users experiencing the same issue on a Windows server and not being able to take ownership as domain admin until locks are cleared.
Based on this experience, I have the following questions:
1) What type of lock will prevent a user (even a builtin administrator) from taking ownership of a file/folder?
2) Why weren't we able to take ownership of the folder until the "read-deny_none" lock was cleared, but this same lock didn't prevent us from taking ownership when I was attempting to reproduce the issue?
3) Why did Ontap report that my builtin adminsitrator account became the owner when looking at the permissions using the "vserver security file-directory" command class, yet when accessing the share via Windows I still received permissions denied when attempting to view the NTFS permissions of the folder?
4) Any thoughts on other tests I can run to attempt and reproduce this issue?
Windows 7 / W2K8 clients
Thanks in advance for any replies!
One of my customer had the same issue and i checked the righful owner of that share from ontap side using the fsecurity command and asked my client to login with the same account in to windows machine after which they were able to take the ownership of the share
Can run the command below to see the rightful owner, you will have a coloumn called owner showing a ID either numeric or alphanumeric
node run –node <nodename> -command fsecurity show <path>
You can change the security ownership by a tool called "secedit". It is available in our support site. Please look at the below link for the process.
For cluster data ontap
The fsecurity command has been replaced by the "vserver security file-directory" command in more recent versions of Ontap, and per my post original post, I leveraged this command to validate who Ontap believed the owner was.
I reviewed the generic troubleshooting links that were referenced prior to engaging support.
i have do some read-up on secedit.exe, looks to me it is only works on 7mode? I was trying to remove "Everyone" from CLi, or even integrate to WFA in the future. But i can't seems find the way. I have tried the options from vserver security file-directory command set but no luck. Appreciate if anyone can shed some light.
File Path: /vol1/qt001
File Inode Number: 97
Security Style: ntfs
Effective Style: ntfs
DOS Attributes: 10
DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
UNIX User Id: 0
UNIX Group Id: 0
UNIX Mode Bits: 777
UNIX Mode Bits in Text: rwxrwxrwx
ACLs: NTFS Security Descriptor
DACL - ACEs