We have an ONTAP 8.0.x filer here serving out a volume with an NTFS qtree via both CIFS and NFS. We're encountering the following situation:
1. An OSX user browses to the path via CIFS in Finder and then walks away/moves on to another task leaving the Finder window open on the path. - This generates a mandatory read lock on the folder (verified via lock status): CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None
2. An NFS client comes along now (automated build process) and attempts delete the same folder. This appears to succeed from the NFS client's perspective. - We now see the following: CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose
At this point, CIFS access to the path now is completely blocked. No one can navigate into the folder, nor view its ACLs (save likely for the OSX client still holding the read lock).
NFS clients can continue to access the contents of the folder (both read/write), but rmdir/rm operations on the folder itself fail with Permission denied.
The fix is to (a) close the Finder window or (b) clear the lock via 'lock break' on the filer.
I'll note that Windows Explorer doesn't appear to open a read lock when you only browse to a path -- not sure why Finder does.
We're looking for options here, but first I'm wondering if the filer's response here isn't ideal. Rather than completing closing off access to CIFS clients, shouldn't #2 above just fail from the get-go rather than generating the DelOnClose queued event (if a mandatory read lock exists on the resource)?
Other options we're considering:
- Modifying automated processes to avoid the "rmdir" command. - Sticking with only one access protocol (likely CIFS). - Modifying OSX Finder behavior to not generate and hold a CIFS read lock (not sure how easy this would be to do). - Finding some sort of tunable on the ONTAP side to minimize impact (e.g. ignore the read lock and let the NFS rmdir operation to succeed) at the potential elevated risk of reduced data integrity.
Anyone have any thoughts/experiences with something similar?
Thanks, Ray
Why not have the MAC use NFS instead of SMB?
--tmac
*Tim McCarthy* *Principal Consultant*
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On Wed, Feb 20, 2013 at 8:59 PM, Ray Van Dolson rvandolson@esri.com wrote:
We have an ONTAP 8.0.x filer here serving out a volume with an NTFS qtree via both CIFS and NFS. We're encountering the following situation:
- An OSX user browses to the path via CIFS in Finder and then walks away/moves on to another task leaving the Finder window open on the path.
- This generates a mandatory read lock on the folder (verified via lock status): CIFS path=\path(/path) host=10.28.102.30() owner=njarecha
state=GRANTED mode=Read-denyN oplock=None
- An NFS client comes along now (automated build process) and attempts delete the same folder. This appears to succeed from the NFS client's perspective.
- We now see the following: CIFS path=\path(/path) host=10.28.102.30() owner=njarecha
state=GRANTED mode=Read-denyN oplock=None CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose
At this point, CIFS access to the path now is completely blocked. No one can navigate into the folder, nor view its ACLs (save likely for the OSX client still holding the read lock).
NFS clients can continue to access the contents of the folder (both read/write), but rmdir/rm operations on the folder itself fail with Permission denied.
The fix is to (a) close the Finder window or (b) clear the lock via 'lock break' on the filer.
I'll note that Windows Explorer doesn't appear to open a read lock when you only browse to a path -- not sure why Finder does.
We're looking for options here, but first I'm wondering if the filer's response here isn't ideal. Rather than completing closing off access to CIFS clients, shouldn't #2 above just fail from the get-go rather than generating the DelOnClose queued event (if a mandatory read lock exists on the resource)?
Other options we're considering:
- Modifying automated processes to avoid the "rmdir" command.
- Sticking with only one access protocol (likely CIFS).
- Modifying OSX Finder behavior to not generate and hold a CIFS read lock (not sure how easy this would be to do).
- Finding some sort of tunable on the ONTAP side to minimize impact (e.g. ignore the read lock and let the NFS rmdir operation to succeed) at the potential elevated risk of reduced data integrity.
Anyone have any thoughts/experiences with something similar?
Thanks, Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
On Wed, Feb 20, 2013 at 09:11:43PM -0500, tmac wrote:
Why not have the MAC use NFS instead of SMB?
--tmac
All of the Macs are joined to AD -- so their randomly generated UID's don't match up with our NIS UID's.
As you know, NFS access on an NTFS qtree works as follows:
NFS UID -> Unix username (in our case looked up via NIS) -> AD username -> NTFS ACL.
The UID passed by the OSX clients is this random large number (not even sure if it's consistent across machines) that does not map to a valid NID username....
We could probably look to use usermap.cfg (we'd have to manually maintain) or override how the Mac does SID -> UID calculations. Ends up not being very simple. :(
Thanks, Ray
On Wed, Feb 20, 2013 at 8:59 PM, Ray Van Dolson rvandolson@esri.com wrote:
We have an ONTAP 8.0.x filer here serving out a volume with an NTFS qtree via both CIFS and NFS. We're encountering the following situation: 1. An OSX user browses to the path via CIFS in Finder and then walks away/moves on to another task leaving the Finder window open on the path. - This generates a mandatory read lock on the folder (verified via lock status): CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state= GRANTED mode=Read-denyN oplock=None 2. An NFS client comes along now (automated build process) and attempts delete the same folder. This appears to succeed from the NFS client's perspective. - We now see the following: CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state= GRANTED mode=Read-denyN oplock=None CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose At this point, CIFS access to the path now is completely blocked. No one can navigate into the folder, nor view its ACLs (save likely for the OSX client still holding the read lock). NFS clients can continue to access the contents of the folder (both read/write), but rmdir/rm operations on the folder itself fail with Permission denied. The fix is to (a) close the Finder window or (b) clear the lock via 'lock break' on the filer. I'll note that Windows Explorer doesn't appear to open a read lock when you only browse to a path -- not sure why Finder does. We're looking for options here, but first I'm wondering if the filer's response here isn't ideal. Rather than completing closing off access to CIFS clients, shouldn't #2 above just fail from the get-go rather than generating the DelOnClose queued event (if a mandatory read lock exists on the resource)? Other options we're considering: - Modifying automated processes to avoid the "rmdir" command. - Sticking with only one access protocol (likely CIFS). - Modifying OSX Finder behavior to not generate and hold a CIFS read lock (not sure how easy this would be to do). - Finding some sort of tunable on the ONTAP side to minimize impact (e.g. ignore the read lock and let the NFS rmdir operation to succeed) at the potential elevated risk of reduced data integrity. Anyone have any thoughts/experiences with something similar? Thanks, Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Which version of OSX?
Can you replicate issue on other data ontap version? Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Ray Van Dolson rvandolson@esri.com Sender: toasters-bounces@teaparty.net Date: Wed, 20 Feb 2013 17:59:10 To: toasters@teaparty.net Subject: Mixed CIFS/NFS Access and issues w/ Locking
We have an ONTAP 8.0.x filer here serving out a volume with an NTFS qtree via both CIFS and NFS. We're encountering the following situation:
1. An OSX user browses to the path via CIFS in Finder and then walks away/moves on to another task leaving the Finder window open on the path. - This generates a mandatory read lock on the folder (verified via lock status): CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None
2. An NFS client comes along now (automated build process) and attempts delete the same folder. This appears to succeed from the NFS client's perspective. - We now see the following: CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose
At this point, CIFS access to the path now is completely blocked. No one can navigate into the folder, nor view its ACLs (save likely for the OSX client still holding the read lock).
NFS clients can continue to access the contents of the folder (both read/write), but rmdir/rm operations on the folder itself fail with Permission denied.
The fix is to (a) close the Finder window or (b) clear the lock via 'lock break' on the filer.
I'll note that Windows Explorer doesn't appear to open a read lock when you only browse to a path -- not sure why Finder does.
We're looking for options here, but first I'm wondering if the filer's response here isn't ideal. Rather than completing closing off access to CIFS clients, shouldn't #2 above just fail from the get-go rather than generating the DelOnClose queued event (if a mandatory read lock exists on the resource)?
Other options we're considering:
- Modifying automated processes to avoid the "rmdir" command. - Sticking with only one access protocol (likely CIFS). - Modifying OSX Finder behavior to not generate and hold a CIFS read lock (not sure how easy this would be to do). - Finding some sort of tunable on the ONTAP side to minimize impact (e.g. ignore the read lock and let the NFS rmdir operation to succeed) at the potential elevated risk of reduced data integrity.
Anyone have any thoughts/experiences with something similar?
Thanks, Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Unsure on that, but will dig in further (not a Mac guy nor do I have direct access to the machines in question currently).
We haven't yet tested on ONTAP 8.1 (and don't have a CIFS licensed 8.1 install in any case) so will need to fire up a simulator to see if we can reproduce there.
Thanks, Ray
On Thu, Feb 21, 2013 at 02:11:58AM +0000, Jack Lyons wrote:
Which version of OSX?
Can you replicate issue on other data ontap version? Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Ray Van Dolson rvandolson@esri.com Sender: toasters-bounces@teaparty.net Date: Wed, 20 Feb 2013 17:59:10 To: toasters@teaparty.net Subject: Mixed CIFS/NFS Access and issues w/ Locking
We have an ONTAP 8.0.x filer here serving out a volume with an NTFS qtree via both CIFS and NFS. We're encountering the following situation:
An OSX user browses to the path via CIFS in Finder and then walks away/moves on to another task leaving the Finder window open on the path.
- This generates a mandatory read lock on the folder (verified via lock status): CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None
An NFS client comes along now (automated build process) and attempts delete the same folder. This appears to succeed from the NFS client's perspective.
- We now see the following: CIFS path=\path(/path) host=10.28.102.30() owner=njarecha state=GRANTED mode=Read-denyN oplock=None CIFS path=\path(-) host= owner= state=GWAITING mode=DelOnClose
At this point, CIFS access to the path now is completely blocked. No one can navigate into the folder, nor view its ACLs (save likely for the OSX client still holding the read lock).
NFS clients can continue to access the contents of the folder (both read/write), but rmdir/rm operations on the folder itself fail with Permission denied.
The fix is to (a) close the Finder window or (b) clear the lock via 'lock break' on the filer.
I'll note that Windows Explorer doesn't appear to open a read lock when you only browse to a path -- not sure why Finder does.
We're looking for options here, but first I'm wondering if the filer's response here isn't ideal. Rather than completing closing off access to CIFS clients, shouldn't #2 above just fail from the get-go rather than generating the DelOnClose queued event (if a mandatory read lock exists on the resource)?
Other options we're considering:
- Modifying automated processes to avoid the "rmdir" command.
- Sticking with only one access protocol (likely CIFS).
- Modifying OSX Finder behavior to not generate and hold a CIFS read lock (not sure how easy this would be to do).
- Finding some sort of tunable on the ONTAP side to minimize impact (e.g. ignore the read lock and let the NFS rmdir operation to succeed) at the potential elevated risk of reduced data integrity.
Anyone have any thoughts/experiences with something similar?
Thanks, Ray
-
Jack Lyons -
Ray Van Dolson -
tmac