Hi Justin,

I think I fired too early - one more thing just popped up. I've set the registry keys for AnonymousUID and AnonymosGID to 0 each and am now able to write to that volume. It's mounted using NFSv3 currently:

Local Remote Properties ------------------------------------------------------------------------------- z: \22.22.222.222\volnXXXXXXX UID=0, GID=0 rsize=65536, wsize=65536 mount=hard, timeout=0.8 retry=1, locking=yes fileaccess=755, lang=ANSI casesensitive=yes sec=sys

I can copy files to this volume, I can delete files, traverse folders, etc. But I - for whatever reason - cannot rename files. When I try to rename a folder, I get:

[cid:image001.png@01D2AF92.DAF808E0]

On the command line, a different error (Access denied) is given:

Z:>move test test1 Access is denied. 0 dir(s) moved.

Z:>ren test test1 Access is denied.

Any idea what I'm missing here now?

Thanks,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Alexander Griesser Gesendet: Donnerstag, 6. April 2017 19:36 An: 'Parisi, Justin' Justin.Parisi@netapp.com; toasters@teaparty.net Betreff: AW: Windows NFS Client + cDOT

Hi Justin,

many thanks for pointing me there - I was still thinking pre 8.3 where this was not possible.

::> vserver nfs modify -vserver VSERVERNAME -v3-ms-dos-client enabled

was all it needed and I could successfully mount the share on a Windows Server 2016 now.

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Parisi, Justin [mailto:Justin.Parisi@netapp.com] Gesendet: Donnerstag, 6. April 2017 19:12 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: RE: Windows NFS Client + cDOT

Windows NFS clients work with cDOT as of 8.2.3 and 8.3.1. TR-4067 covers this on page 116.

http://www.netapp.com/us/media/tr-4067.pdf

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Alexander Griesser Sent: Thursday, April 6, 2017 1:07 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: Windows NFS Client + cDOT

Hey there,

is it still true that Windows' integrated NFS client is unable to mount NFS shares from cDOT systems? Just asking because I was trying to do so again today out of curiosity and failed miserably again. If this is still the case, can anyone recommend alternative NFS clients for windows?

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Hi Justin,

Yes, I did activate v3-ms-dos-client and deactivated enabe-ejukebox and v3-connection-drop:

::*> vserver nfs show -vserver XXXXXXX -fields enable-ejukebox,v3-connection-drop,v3-ms-dos-client vserver enable-ejukebox v3-connection-drop v3-ms-dos-client ------- --------------- ------------------ ---------------- XXXXXXX false disabled enabled

Here's the export policy:

::*> vserver export-policy rule show -vserver XXXXXX -policyname XXXXXX -instance

Vserver: XXXXXX Policy Name: XXXXXX Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 22.22.22.22 RO Access Rule: any RW Access Rule: any User ID To Which Anonymous Users Are Mapped: 0 Superuser Security Types: any Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true NTFS Unix Security Options: fail Vserver NTFS Unix Security Options: use_export_policy Change Ownership Mode: restricted Vserver Change Ownership Mode: use_export_policy

Here's the file-directory show output of the base volume itself:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME

Vserver: XXXXXX File Path: /VOLUME File Inode Number: 64 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

And here it is for the directory I'm trying to rename:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME/test

Vserver: XXXXXX File Path: /VOLUME/test File Inode Number: 22620 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

Thanks,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Parisi, Justin [mailto:Justin.Parisi@netapp.com] Gesendet: Freitag, 7. April 2017 15:41 An: Alexander Griesser AGriesser@anexia-it.com; toasters@teaparty.net Betreff: RE: Windows NFS Client + cDOT

Did you make the modifications mentioned in the TR to the NFS options?

Also, what does your export policy rule look like?

What does "vserver security file-directory show" give you for the newly created file? Who is the owner/what are the perms?

From: Alexander Griesser [mailto:AGriesser@anexia-it.com] Sent: Friday, April 7, 2017 5:35 AM To: Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Subject: AW: Windows NFS Client + cDOT

Hi Justin,

I think I fired too early - one more thing just popped up. I've set the registry keys for AnonymousUID and AnonymosGID to 0 each and am now able to write to that volume. It's mounted using NFSv3 currently:

Local Remote Properties ------------------------------------------------------------------------------- z: \22.22.222.222\volnXXXXXXXfile://22.22.222.222/volnXXXXXXX UID=0, GID=0 rsize=65536, wsize=65536 mount=hard, timeout=0.8 retry=1, locking=yes fileaccess=755, lang=ANSI casesensitive=yes sec=sys

I can copy files to this volume, I can delete files, traverse folders, etc. But I - for whatever reason - cannot rename files. When I try to rename a folder, I get:

[cid:image001.png@01D2AFD6.A7E65D00]

On the command line, a different error (Access denied) is given:

Z:>move test test1 Access is denied. 0 dir(s) moved.

Z:>ren test test1 Access is denied.

Any idea what I'm missing here now?

Thanks,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Alexander Griesser Gesendet: Donnerstag, 6. April 2017 19:36 An: 'Parisi, Justin' <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: AW: Windows NFS Client + cDOT

Hi Justin,

many thanks for pointing me there - I was still thinking pre 8.3 where this was not possible.

::> vserver nfs modify -vserver VSERVERNAME -v3-ms-dos-client enabled

was all it needed and I could successfully mount the share on a Windows Server 2016 now.

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Parisi, Justin [mailto:Justin.Parisi@netapp.com] Gesendet: Donnerstag, 6. April 2017 19:12 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: RE: Windows NFS Client + cDOT

Windows NFS clients work with cDOT as of 8.2.3 and 8.3.1. TR-4067 covers this on page 116.

http://www.netapp.com/us/media/tr-4067.pdf

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Alexander Griesser Sent: Thursday, April 6, 2017 1:07 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: Windows NFS Client + cDOT

Hey there,

is it still true that Windows' integrated NFS client is unable to mount NFS shares from cDOT systems? Just asking because I was trying to do so again today out of curiosity and failed miserably again. If this is still the case, can anyone recommend alternative NFS clients for windows?

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Well, there are like 70 export policies on this SVM for 70 different volumes, I guess the policy for this volume as well as the default policy for the SVM will suffice here? If so, the export policy for this volume has already been sent earlier and here’s the default policy for this SVM:

::> export-policy rule show -vserver XXXXXXX -policyname default -instance

Vserver: XXXXXXX Policy Name: default Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 0/0 RO Access Rule: any RW Access Rule: never User ID To Which Anonymous Users Are Mapped: 65535 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Freitag, 7. April 2017 20:15 An: Alexander Griesser AGriesser@anexia-it.com Cc: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Betreff: Re: Windows NFS Client + cDOT

yes, yes..

export policy rule show -instance (please)

--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam

I Blog at TMACsRackhttps://tmacsrack.wordpress.com/

On Fri, Apr 7, 2017 at 1:45 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Hi Justin,

Yes, I did activate v3-ms-dos-client and deactivated enabe-ejukebox and v3-connection-drop:

::*> vserver nfs show -vserver XXXXXXX -fields enable-ejukebox,v3-connection-drop,v3-ms-dos-client vserver enable-ejukebox v3-connection-drop v3-ms-dos-client ------- --------------- ------------------ ---------------- XXXXXXX false disabled enabled

Here’s the export policy:

::*> vserver export-policy rule show -vserver XXXXXX -policyname XXXXXX -instance

Vserver: XXXXXX Policy Name: XXXXXX Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 22.22.22.22 RO Access Rule: any RW Access Rule: any User ID To Which Anonymous Users Are Mapped: 0 Superuser Security Types: any Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true NTFS Unix Security Options: fail Vserver NTFS Unix Security Options: use_export_policy Change Ownership Mode: restricted Vserver Change Ownership Mode: use_export_policy

Here’s the file-directory show output of the base volume itself:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME

Vserver: XXXXXX File Path: /VOLUME File Inode Number: 64 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

And here it is for the directory I’m trying to rename:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME/test

Vserver: XXXXXX File Path: /VOLUME/test File Inode Number: 22620 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

Thanks,

Alexander Griesser

Yes, I’ve set anon in the export policy for the volume it self to 0 and I’ve set the registry keys on windows for AnonymousUID and AnonymousGID to 0 – without the registry keys, it will be „-2“ on the mount options in windows, whatever that negative value is used for… If the permissions were wrong, I could not create files at all in the first place, I guess, right? But I can create them and they show as UID 0 on the filer (also tested on a linux system where I mounted this volume) – and I can delete the files as well. The only thing which is not working, is renaming and I’m not sure why it’s refusing to do so. Maybe this is a Win 2k16 thinggie? I can try to spin up a Win2k12 system to see if this problem also persists there, that would at least rule out a misconfiguration on the filer I guess.

I did not create separate policies for the SVM root, the SVM root only gets applied the default policy here and the default policy iss et to „ro all“, „rw never“ – as you can see below.

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Freitag, 7. April 2017 20:24 An: Alexander Griesser AGriesser@anexia-it.com Cc: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Betreff: Re: Windows NFS Client + cDOT

Not sure if this is it or not, but you have said that you set the anon ID's to 0. In this policy, it is set to 65535

Do you create separate policies for the SVM root and the data volumes? If you do, Root could/should be allow RO to all, rw to none. Then set the restrictions on the data volume policy.

--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam

I Blog at TMACsRackhttps://tmacsrack.wordpress.com/

On Fri, Apr 7, 2017 at 2:19 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Well, there are like 70 export policies on this SVM for 70 different volumes, I guess the policy for this volume as well as the default policy for the SVM will suffice here? If so, the export policy for this volume has already been sent earlier and here’s the default policy for this SVM:

::> export-policy rule show -vserver XXXXXXX -policyname default -instance

Vserver: XXXXXXX Policy Name: default Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 0/0 RO Access Rule: any RW Access Rule: never User ID To Which Anonymous Users Are Mapped: 65535 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: tmac [mailto:tmacmd@gmail.commailto:tmacmd@gmail.com] Gesendet: Freitag, 7. April 2017 20:15 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Windows NFS Client + cDOT

yes, yes..

export policy rule show -instance (please)

--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam

I Blog at TMACsRackhttps://tmacsrack.wordpress.com/

On Fri, Apr 7, 2017 at 1:45 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Hi Justin,

Yes, I did activate v3-ms-dos-client and deactivated enabe-ejukebox and v3-connection-drop:

::*> vserver nfs show -vserver XXXXXXX -fields enable-ejukebox,v3-connection-drop,v3-ms-dos-client vserver enable-ejukebox v3-connection-drop v3-ms-dos-client ------- --------------- ------------------ ---------------- XXXXXXX false disabled enabled

Here’s the export policy:

::*> vserver export-policy rule show -vserver XXXXXX -policyname XXXXXX -instance

Vserver: XXXXXX Policy Name: XXXXXX Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 22.22.22.22 RO Access Rule: any RW Access Rule: any User ID To Which Anonymous Users Are Mapped: 0 Superuser Security Types: any Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true NTFS Unix Security Options: fail Vserver NTFS Unix Security Options: use_export_policy Change Ownership Mode: restricted Vserver Change Ownership Mode: use_export_policy

Here’s the file-directory show output of the base volume itself:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME

Vserver: XXXXXX File Path: /VOLUME File Inode Number: 64 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

And here it is for the directory I’m trying to rename:

::*> vserver security file-directory show -vserver XXXXXX -path /VOLUME/test

Vserver: XXXXXX File Path: /VOLUME/test File Inode Number: 22620 Security Style: unix Effective Style: unix DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 0 UNIX Group Id: 0 UNIX Mode Bits: 755 UNIX Mode Bits in Text: rwxr-xr-x ACLs: -

Thanks,

Alexander Griesser

Ok, started playing around with this today. This is my mount:

Z:>mount

Local Remote Properties ------------------------------------------------------------------------------- Z: \demo\flexvol UID=0, GID=0 rsize=65536, wsize=65536 mount=hard, timeout=0.8 retry=1, locking=yes fileaccess=755, lang=ANSI casesensitive=no sec=sys

When I try to rename via the GUI, I get this:

[cid:image001.png@01D2B212.D5E473C0]

Via CLI, I get this:

Z:>ren "New Text Document (2).txt" test.txt

Z:>dir Volume in drive Z has no label. Volume Serial Number is 80F0-372F

Directory of Z:\

04/10/2017 03:49 PM <DIR> . 04/10/2017 03:49 PM <DIR> .. 04/10/2017 03:45 PM 0 New Text Document.txt 04/10/2017 03:46 PM 0 test.txt 04/10/2017 03:45 PM <DIR> .snapshot 2 File(s) 12,288 bytes 3 Dir(s) 1,044,535,574,528 bytes free

A search for “invalid device” gets me this:

https://support.microsoft.com/en-us/help/3025097/-invalid-device-error-when-...

I tried to apply it to my server, but it claims it’s not valid for Windows 2012R2, even though it’s specifically for Win 2012R2. ¯_(ツ)_/¯

Packet traces and sktraces on the cluster suggest the issue isn’t on the cluster side; the rename request never happens from the client:

[cid:image002.png@01D2B217.78F24160]

Does it fail for you the same way? Does rename work from CLI? On my end, at least, this seems to be a client issue.

From: Alexander Griesser [mailto:AGriesser@anexia-it.com] Sent: Monday, April 10, 2017 4:26 AM To: NGC-tmacmd-gmail.com tmacmd@gmail.com Cc: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: AW: Windows NFS Client + cDOT

Hey everyone,

we’ve just set up a Windows 2k12 system and the renaming of files and folders doesn’t work there too, so it’s not a Windows 2016 problem. Any further ideas on how to debug this issue?

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Alexander Griesser Gesendet: Freitag, 7. April 2017 20:30 An: 'tmac' <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: AW: Windows NFS Client + cDOT

Yes, I’ve set anon in the export policy for the volume it self to 0 and I’ve set the registry keys on windows for AnonymousUID and AnonymousGID to 0 – without the registry keys, it will be „-2“ on the mount options in windows, whatever that negative value is used for… If the permissions were wrong, I could not create files at all in the first place, I guess, right? But I can create them and they show as UID 0 on the filer (also tested on a linux system where I mounted this volume) – and I can delete the files as well. The only thing which is not working, is renaming and I’m not sure why it’s refusing to do so. Maybe this is a Win 2k16 thinggie? I can try to spin up a Win2k12 system to see if this problem also persists there, that would at least rule out a misconfiguration on the filer I guess.

I did not create separate policies for the SVM root, the SVM root only gets applied the default policy here and the default policy iss et to „ro all“, „rw never“ – as you can see below.

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Freitag, 7. April 2017 20:24 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Windows NFS Client + cDOT

Not sure if this is it or not, but you have said that you set the anon ID's to 0. In this policy, it is set to 65535

Do you create separate policies for the SVM root and the data volumes? If you do, Root could/should be allow RO to all, rw to none. Then set the restrictions on the data volume policy.

--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam

I Blog at TMACsRackhttps://tmacsrack.wordpress.com/

On Fri, Apr 7, 2017 at 2:19 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Well, there are like 70 export policies on this SVM for 70 different volumes, I guess the policy for this volume as well as the default policy for the SVM will suffice here? If so, the export policy for this volume has already been sent earlier and here’s the default policy for this SVM:

::> export-policy rule show -vserver XXXXXXX -policyname default -instance

Vserver: XXXXXXX Policy Name: default Rule Index: 1 Access Protocol: nfs List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 0/0 RO Access Rule: any RW Access Rule: never User ID To Which Anonymous Users Are Mapped: 65535 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

Best,

Alexander Griesser Head of Systems Operations

ANEXIA Internetdienstleistungs GmbH

E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: tmac [mailto:tmacmd@gmail.commailto:tmacmd@gmail.com] Gesendet: Freitag, 7. April 2017 20:15 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com>; toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Windows NFS Client + cDOT

yes, yes..

export policy rule show -instance (please)

--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam

I Blog at TMACsRackhttps://tmacsrack.wordpress.com/