Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the UNIX user account looses access to the UNIX QTREE after the copy if made from QT1 to QT2. Does anyone know what could cause this and how I can get around it? Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described .. (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the UNIX user account looses access to the UNIX QTREE after the copy if made from QT1 to QT2. Does anyone know what could cause this and how I can get around it? Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
Just 2 Files within the QTREE..
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.com wrote:
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described .. (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made from
QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the UNIX user account looses access to the UNIX QTREE after the copy if made from QT1 to QT2. Does anyone know what could cause this and how I can get around it? Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.com wrote:
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made from
QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
In a nutshell no, the only file level copy you can perform on a filer's console is ndmpcopy. When you copy from a Unix to an NTFS qtree (or vice versa) all sorts of strange permission based problems occur as NTFS and Unix permissions are not interchangeable. Why do you need to copy between the 2 qtrees? I would personally set up a single Unix qtree and do some CIFS user and group mappings to allow windows (CIFS) access. It's easier to do it this way round I have found, but most importantly, STAY AWAY FROM MIXED QTREES.
I hope that helps,
Jeffers.
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: 17 October 2008 16:04 To: Nils Vogels Cc: toasters@mathworks.com Subject: Re: File Copy between NTFS & UNIX Qtrees
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.com wrote:
Are you copying the entire qtree, or specific files? If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well ).. On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote: > Hi Toasters, > > I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be > passed between the 2 QTREES in both directions which I am doing using > ndmpcopy. However an unexpected consequence of this action is that the UNIX > user account looses access to the UNIX QTREE after the copy if made from QT1 > to QT2. Does anyone know what could cause this and how I can get around it? > Both QTREEs are in the same Volume but I would not expect this to be > relevant. > > thanks, > Jimmy -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
-------------------------------------------------------------------------------- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.dresdnerkleinwort.com/disc/email/ or contact the sender. --------------------------------------------------------------------------------
Paradoxically we are copying over account information to maintain up to date entries in our usermap.cfg & passwd files on the Filer to allow UNIX clients access to NTFS volumes. We can use the same files to allow the relevant UNIX account access to a NTFS share but it increases the likelihood of failure in the process. For now however this does look like our best option. However from my understanding using NDMPCOPY to copy files from NTFS to UNIX should not have this type of security implication as it should not attempt to copy over ACL information so I am very surprised by what is happening.
rgds, J
On Fri, Oct 17, 2008 at 5:50 PM, Jeffries, Mark Mark.Jeffries@dkib.comwrote:
In a nutshell no, the only file level copy you can perform on a filer's console is ndmpcopy. When you copy from a Unix to an NTFS qtree (or vice versa) all sorts of strange permission based problems occur as NTFS and Unix permissions are not interchangeable. Why do you need to copy between the 2 qtrees? I would personally set up a single Unix qtree and do some CIFS user and group mappings to allow windows (CIFS) access. It's easier to do it this way round I have found, but most importantly, STAY AWAY FROM MIXED QTREES.
I hope that helps,
Jeffers.
*From:* owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] *On Behalf Of *Jimmy Corncrake *Sent:* 17 October 2008 16:04 *To:* Nils Vogels *Cc:* toasters@mathworks.com *Subject:* Re: File Copy between NTFS & UNIX Qtrees
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.comwrote:
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to
be
passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made from
QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.dresdnerkleinwort.com/disc/email/ or contact the sender.
Paradoxically we are copying over account information to maintain up to date entries in our usermap.cfg & passwd files on the Filer to allow UNIX clients access to NTFS volumes. We can use the same files to allow the relevant UNIX account access to a NTFS share but it increases the likelihood of failure in the process. For now however this does look like our best option. However from my understanding using NDMPCOPY to copy files from NTFS to UNIX should not have this type of security implication as it should not attempt to copy over ACL information so I am very surprised by what is happening.
rgds, J
On Fri, Oct 17, 2008 at 5:50 PM, Jeffries, Mark Mark.Jeffries@dkib.comwrote:
In a nutshell no, the only file level copy you can perform on a filer's console is ndmpcopy. When you copy from a Unix to an NTFS qtree (or vice versa) all sorts of strange permission based problems occur as NTFS and Unix permissions are not interchangeable. Why do you need to copy between the 2 qtrees? I would personally set up a single Unix qtree and do some CIFS user and group mappings to allow windows (CIFS) access. It's easier to do it this way round I have found, but most importantly, STAY AWAY FROM MIXED QTREES.
I hope that helps,
Jeffers.
*From:* owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] *On Behalf Of *Jimmy Corncrake *Sent:* 17 October 2008 16:04 *To:* Nils Vogels *Cc:* toasters@mathworks.com *Subject:* Re: File Copy between NTFS & UNIX Qtrees
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.comwrote:
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to
be
passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made from
QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.dresdnerkleinwort.com/disc/email/ or contact the sender.
I think it may be trying to "place the ACL within UNIX perms" and if you watch carefully, I have noticed that it could even change every directory up to the top level applying the NDMPcopied ACL.
--tmac
RedHat Certified Engineer #804006984323821 (RHEL4) RedHat Certified Engineer #805007643429572 (RHEL5)
Principal Consultant
On Sat, Oct 18, 2008 at 10:00 AM, Jimmy Corncrake oisintno@gmail.comwrote:
Paradoxically we are copying over account information to maintain up to date entries in our usermap.cfg & passwd files on the Filer to allow UNIX clients access to NTFS volumes. We can use the same files to allow the relevant UNIX account access to a NTFS share but it increases the likelihood of failure in the process. For now however this does look like our best option. However from my understanding using NDMPCOPY to copy files from NTFS to UNIX should not have this type of security implication as it should not attempt to copy over ACL information so I am very surprised by what is happening.
rgds, J
On Fri, Oct 17, 2008 at 5:50 PM, Jeffries, Mark Mark.Jeffries@dkib.comwrote:
In a nutshell no, the only file level copy you can perform on a filer's console is ndmpcopy. When you copy from a Unix to an NTFS qtree (or vice versa) all sorts of strange permission based problems occur as NTFS and Unix permissions are not interchangeable. Why do you need to copy between the 2 qtrees? I would personally set up a single Unix qtree and do some CIFS user and group mappings to allow windows (CIFS) access. It's easier to do it this way round I have found, but most importantly, STAY AWAY FROM MIXED QTREES.
I hope that helps,
Jeffers.
*From:* owner-toasters@mathworks.com [mailto: owner-toasters@mathworks.com] *On Behalf Of *Jimmy Corncrake *Sent:* 17 October 2008 16:04 *To:* Nils Vogels *Cc:* toasters@mathworks.com *Subject:* Re: File Copy between NTFS & UNIX Qtrees
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.comwrote:
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to
be
passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made
from QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.dresdnerkleinwort.com/disc/email/ or contact the sender
Honestly your safest option in this scenario is to do the copy from a client of the appropriate OS.
- For copying Windows to UNIX, use a UNIX (NFS) client. - For UNIX to Windows, use a Windows (CIFS) client.
That way permissions will be set according to the correct OS semantics for the recipient qtree.
You need to have at least one account on each platform which can read data on the other platform's qtree. In your environment that account may be regarded as privileged.
If you are using inherited ACLs on the Windows side then you can use a UNIX host to copy in both directions. Obviously the UNIX host account would then need write access to the file on the Windows qtree.
Using a Windows client to copy data to the UNIX permissions qtree can be done, but you will likely find the permissions to be not what you want.
-j
-- Jeremy Webber Senior Systems Engineer T: +61 2 9383 4837 F: +61 2 9383 4801
Animal Logic http://www.animallogic.com
Please think of the environment before printing this email.
This email and any attachments may be confidential and/or privileged. If you are not the intended recipient of this email, you must not disclose or use the information contained in it. Please notify the sender immediately and delete this document if you have received it in error. We do not guarantee this email is error or virus free.
Agree with Jeffers.
I believe there is a possibility of leveraging the "usermag.cfg" file to work around the user access rights mapping issues. The file copy is probably resulting in user access rights of nobody on the unix side which is probably no access on the unix qtree.
Have you tried that ?
Manish A Kinnerkar
"Jeffries, Mark" Mark.Jeffries@dkib.com Sent by: owner-toasters@mathworks.com 10/17/2008 09:20 PM
To "Jimmy Corncrake" oisintno@gmail.com, "Nils Vogels" bacardicoke@gmail.com cc toasters@mathworks.com Subject RE: File Copy between NTFS & UNIX Qtrees
In a nutshell no, the only file level copy you can perform on a filer's console is ndmpcopy. When you copy from a Unix to an NTFS qtree (or vice versa) all sorts of strange permission based problems occur as NTFS and Unix permissions are not interchangeable. Why do you need to copy between the 2 qtrees? I would personally set up a single Unix qtree and do some CIFS user and group mappings to allow windows (CIFS) access. It's easier to do it this way round I have found, but most importantly, STAY AWAY FROM MIXED QTREES.
I hope that helps,
Jeffers.
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: 17 October 2008 16:04 To: Nils Vogels Cc: toasters@mathworks.com Subject: Re: File Copy between NTFS & UNIX Qtrees
Hi, we are copying over just single files not the complete qtree. The UNIX secured QTREE is accessible until we copy over a single file from the the NFTS QTREE which result in permission denied. It should not copy the permissions when the destination is UNIX but this appears to be happening.
Is there anything else I can use apart from ndmpcopy to make the single file copy within the filer console?
On Fri, Oct 17, 2008 at 3:37 PM, Nils Vogels bacardicoke@gmail.com wrote: Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to
be
passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the
UNIX
user account looses access to the UNIX QTREE after the copy if made from
QT1
to QT2. Does anyone know what could cause this and how I can get around
it?
Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
-------------------------------------------------------------------------------- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.dresdnerkleinwort.com/disc/email/ or contact the sender. --------------------------------------------------------------------------------
Generally, this communication is for informational purposes only and it is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. In the event you are receiving the offering materials attached below related to your interest in hedge funds or private equity, this communication may be intended as an offer or solicitation for the purchase or sale of such fund(s). All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.
Hi guys, im seeing this behavior on different MS windows clusters attached to our FAS960, the most weird part is that i see the active node of the windows cluster connected to the target portal, but from the filer i dont see the igroup logged in for almost 2 minutes and thats when the windows clusters hung because they cant mount the quorum lun. All these while doiing a cf takeover.
I talked to probably 10 Netapp support engineers and no one can explain it.
Has anyone seen anything like this before? I have installed Host Utilities 5 and checked the windows registry to make sure the values have been tuned.
Thanks
Chris
We have had several clusters that have worked fine over take overs (just went through 6 panics after upgrading to 7.2.6!)., but since you mention igroups - I assume you are using iscsi for the luns. We are using fcp.
I assume you are using 3 seperate network interfaces for iscsi traffic and the intra cluster and public traffic?
Jack
On 11/21/08, Cristian Rojas intipu@yahoo.com wrote:
Hi guys, im seeing this behavior on different MS windows clusters attached to our FAS960, the most weird part is that i see the active node of the windows cluster connected to the target portal, but from the filer i dont see the igroup logged in for almost 2 minutes and thats when the windows clusters hung because they cant mount the quorum lun. All these while doiing a cf takeover.
I talked to probably 10 Netapp support engineers and no one can explain it.
Has anyone seen anything like this before? I have installed Host Utilities 5 and checked the windows registry to make sure the values have been tuned.
Thanks
Chris
Hi Jack, we are using 2 standalone interfaces for iscsi, and a team of 2 interfaces for intra and cluster traffic.
thanks
Chris
________________________________ From: Jack Lyons jack1729@gmail.com To: Cristian Rojas intipu@yahoo.com; toasters@mathworks.com Sent: Saturday, November 22, 2008 1:21:00 AM Subject: Re: cf takeover hungs Microsoft Windows Clusters
We have had several clusters that have worked fine over take overs (just went through 6 panics after upgrading to 7.2.6!)., but since you mention igroups - I assume you are using iscsi for the luns. We are using fcp.
I assume you are using 3 seperate network interfaces for iscsi traffic and the intra cluster and public traffic?
Jack
On 11/21/08, Cristian Rojas intipu@yahoo.com wrote:
Hi guys, im seeing this behavior on different MS windows clusters attached to our FAS960, the most weird part is that i see the active node of the windows cluster connected to the target portal, but from the filer i dont see the igroup logged in for almost 2 minutes and thats when the windows clusters hung because they cant mount the quorum lun. All these while doiing a cf takeover.
I talked to probably 10 Netapp support engineers and no one can explain it.
Has anyone seen anything like this before? I have installed Host Utilities 5 and checked the windows registry to make sure the values have been tuned.
Thanks
Chris
Are you copying the entire qtree, or specific files?
If you are copying the entire qtree, it is likely that ndmpcopy copies the qtree security style as well, causing the problems you described . (and others as well )..
On Fri, Oct 17, 2008 at 3:14 PM, Jimmy Corncrake oisintno@gmail.com wrote:
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the UNIX user account looses access to the UNIX QTREE after the copy if made from QT1 to QT2. Does anyone know what could cause this and how I can get around it? Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks, Jimmy
NDMPcopy will copy the data as-is from src to dst. So it's copying the NTFS ACL's.check that your UNIX user is supposed to have access to the data via NTFS ACL's.
Check that your qtree security has changed from unix to ntfs.
Solution is to either a) allow your unix user access via the NTFS ACL's on QT1 b) use different non-block file copy method.
Best regards,
~~~~~~~~~~~~~~~~
Kevin Parker
Mobile: 919.606.8737
blocked::http://theparkerz.com/ http://theparkerz.com
~~~~~~~~~~~~~~~~
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jimmy Corncrake Sent: Friday, October 17, 2008 9:15 AM To: toasters@mathworks.com Subject: File Copy between NTFS & UNIX Qtrees
Hi Toasters,
I have setup 2 qtrees. QT1 is NTFS and QT2 is UNIX. File Data needs to be passed between the 2 QTREES in both directions which I am doing using ndmpcopy. However an unexpected consequence of this action is that the UNIX user account looses access to the UNIX QTREE after the copy if made from QT1 to QT2. Does anyone know what could cause this and how I can get around it? Both QTREEs are in the same Volume but I would not expect this to be relevant.
thanks,
Jimmy
-
Cristian Rojas -
Jack Lyons -
Jeffries, Mark -
Jeremy Webber -
Jimmy Corncrake -
Kevin M. Parker -
manish.a.kinnerkar＠jpmorgan.com -
Nils Vogels -
tmac