minor edits after recoding based on Word

Author: b-hchen

articles/azure-netapp-files/dual-protocol-permission-behaviors.md

@@ -43,7 +43,7 @@ In a dual-protocol NAS environment, only one security permission style can be ac
 | Security style | Considerations |
 | - | - |
 | UNIX | <ul><li>Windows clients can only set UNIX permission attributes through SMBs that map to UNIX attributes (Read/Write/Execute only; no special permissions). </li> <li>NFSv4.x ACLs don't have GUI management. Management is done only via CLI using [nfs4_getfacl and nfs4_setfacl commands](https://manpages.debian.org/testing/nfs4-acl-tools/index.html). </li> <li> If a file or folder has NFSv4.x ACLs, the Windows security properties tab can't display them. </li></ul>| 
-| NTFS | <ul><li> UNIX clients can't set attributes through NFS via commands such as `chown/chmod`.  </li>  <li>NFS clients show only approximated NTFS permissions when using ls commands. For instance, if a user has a permission in a Windows NTFS ACL that can't be cleanly translated into a POSIX mode bit (such as traverse directory), it's translated into the closest POSIX mode-bit value (such as `1` for execute). </li></ul>|
+| NTFS | <ul><li> UNIX clients can't set attributes through NFS via commands such as `chown/chmod`.  </li>  <li>NFS clients show only approximated NTFS permissions when using `ls` commands. For instance, if a user has a permission in a Windows NTFS ACL that can't be cleanly translated into a POSIX mode bit (such as traverse directory), it's translated into the closest POSIX mode-bit value (such as `1` for execute). </li></ul>|
 
 The selection of volume security style determines how the name mapping for a user is performed. This operation is the core piece of how dual-protocol volumes maintain predictable permissions regardless of protocol in use.
 
@@ -69,7 +69,7 @@ When a user attempts to access an Azure NetApp Files volume, that attempt passes
 
 After a user name is authenticated and validated by Azure NetApp Files, the next step for dual-protocol volume authentication is the mapping of user names for UNIX and Windows interoperability.
 
-A volume's security style determines how a name mapping takes place in Azure NetApp Files. Windows and UNIX permission semantics are different. If a name mapping can't be performed, then authentication fails, and access to a volume from a client is denied. A common scenario where this situation occurs is when NFSv3 access is attempted to a volume with NTFS security style. The initial access request from NFSv3 comes to Azure NetApp Files as a numeric UID. If a user named `user1` with a numeric ID of `1001` tries to access the NFSv3 mount, the authentication request arrives as numeric ID `1001`. Azure NetApp Files then takes numeric ID `1001` and attempts to resolve `1001` to a user name. This user name is required for mapping to a valid Windows user, because the NTFS permissions on the volume contain Windows user names rather than a numeric ID. Azure NetApp Files uses the configured name service server (LDAP) to search for the user name. If the user name can't be found, then authentication fails, and access is denied. This operation is by design in order to prevent unwanted access to files and folders.
+A volume's security style determines how a name mapping takes place in Azure NetApp Files. Windows and UNIX permission semantics are different. If a name mapping can't be performed, then authentication fails, and access to a volume from a client is denied. A common scenario where this situation occurs is when NFSv3 access is attempted to a volume with NTFS security style. The initial access request from NFSv3 comes to Azure NetApp Files as a numeric UID. If a user named `user1` with a numeric ID of `1001` tries to access the NFSv3 mount, the authentication request arrives as numeric ID `1001`. Azure NetApp Files then takes numeric ID `1001` and attempts to resolve `1001` to a user name. This user name is required for mapping to a valid Windows user, because the NTFS permissions on the volume will contain Windows user names instead of a numeric ID. Azure NetApp Files will use the configured name service server (LDAP) to search for the user name. If the user name can't be found, then authentication fails, and access is denied. This operation is by design in order to prevent unwanted access to files and folders.
 
 ## Name mapping based on security style
 

articles/azure-netapp-files/lightweight-directory-access-protocol.md

@@ -124,7 +124,7 @@ The following section discusses the basics of LDAP as it pertains to Azure NetAp
 
 Name mapping rules can be broken down into two main types: *symmetric* and *asymmetric*.
 
-* *Symmetric* name mapping is implicit name mapping between UNIX and Windows users who use the same user name; for example, Windows user `CONTOSO\user1` maps to UNIX user `user1`.  
+* *Symmetric* name mapping is implicit name mapping between UNIX and Windows users who use the same user name. For example, Windows user `CONTOSO\user1` maps to UNIX user `user1`.  
 * *Asymmetric* name mapping is name mapping between UNIX and Windows users who use **different** user names. For example, Windows user `CONTOSO\user1` maps to UNIX user `user2`.
 
 By default, Azure NetApp Files uses symmetric name mapping rules. If asymmetric name mapping rules are required, consider configuring the LDAP user objects to use them.
@@ -172,6 +172,6 @@ This RFC extension fits nicely into how Microsoft Active Directory manages users
 ## Next Steps
 
 * [Configure AD DS LDAP over TLS for Azure NetApp Files](configure-ldap-over-tls.md) 
-* [Understand NFS Group memberships and supplemental groups](network-file-system-group-memberships.md)
+* [Understand NFS group memberships and supplemental groups](network-file-system-group-memberships.md)
 * [Azure NetApp Files NFS FAQ](faq-nfs.md)
 * [Azure NetApp Files SMB FAQ](faq-smb.md)

articles/azure-netapp-files/network-attached-storage-protocols.md

@@ -159,7 +159,7 @@ When a NAS client requests access to a dual-protocol volume in Azure NetApp File
 
 In the following illustration, `user1` authenticates to Azure NetApp Files to access a dual-protocol volume through either SMB or NFS. Azure NetApp Files finds the user’s Windows and UNIX information in Azure Active Directory and then maps the user's Windows and UNIX identities one-to-one. The user is verified as `user1` and gets `user1`'s access credentials. 
 
-In this instance, `user1` gets full control on their own folder (`user1-dir`) and no access to the HR folder. This setting is based on the security ACLs specified in the file system, and `user1` will get the expected access regardless of which protocol they're accessing the volumes from.
+In this instance, `user1` gets full control on their own folder (`user1-dir`) and no access to the `HR` folder. This setting is based on the security ACLs specified in the file system, and `user1` will get the expected access regardless of which protocol they're accessing the volumes from.
 
 :::image type="content" source="../media/azure-netapp-files/user1-dual-protocol-example.png" alt-text="Example of user accessing a dual-protocol volume with Azure NetApp Files." lightbox="../media/azure-netapp-files/user1-dual-protocol-example.png":::
 
@@ -179,9 +179,10 @@ When you use Azure NetApp Files volumes for access to both SMB and NFS, some con
 
 ## Next steps 
 
-* [Understand file locking and lock types in Azure NetApp Files](understand-file-locks.md)
+
 * [Understand dual-protocol security style and permission behaviors in Azure NetApp Files](dual-protocol-permission-behaviors.md)
 * [Understand the use of LDAP with Azure NetApp Files](lightweight-directory-access-protocol.md) 
-* [Understand NFS Group memberships and supplemental groups](network-file-system-group-memberships.md)
+* [Understand NFS group memberships and supplemental groups](network-file-system-group-memberships.md)
+* [Understand file locking and lock types in Azure NetApp Files](understand-file-locks.md)
 * [Azure NetApp Files NFS FAQ](faq-nfs.md)
 * [Azure NetApp Files SMB FAQ](faq-smb.md)