Ce contenu est traduit automatiquement. Veuillez consulter la Clause de non-responsabilité relative à la traduction automatique.

Why can’t I overwrite files on a QNAP NAS when accessing it via Client for NFS on a Windows Server?

Pourquoi ne puis-je pas écraser des fichiers sur un NAS QNAP lorsque j'y accède via Client pour NFS sur un serveur Windows ?

Date de la dernière modification : 2026-01-07

Applicable Products

All QNAP NAS series
Windows Server (any supported version)

Scenario

A user accesses a QNAP NAS shared folder via Network File Services (NFS) from a Windows Server running a supported version. When copying a file with the same name, Windows displays the Replace or Skip Files prompt, indicating that an existing file is present on the NAS.

However, after selecting Replace the file in the destination, the operation fails with an access denied or permission error, preventing the file from being overwritten or updated.

Root Cause

This behavior is a known limitation of the Client for NFS feature in Windows Server and is independent of the NAS configuration. The same behavior is observed across all supported Windows Server versions that include Client for NFS.

Client for NFS supports only NFSv2 and NFSv3 and does not support NFSv4 ACLs. As a result, it cannot negotiate or modify POSIX ACLs over NFS.
By default, Client for NFS accesses NFS shares using an anonymous UID and GID. If the NAS does not grant write permissions to this anonymous identity, write operations fail.
Access is denied unless the anonymous UID and GID are explicitly mapped to a UID and GID that the NAS recognizes and allows to write to the shared folder, regardless of the shared folder’s configured write permissions.

Note

These settings must be configured on the Windows Server.

Solution

To resolve this issue, map the anonymous NFS user on the Windows Server to a UID and GID that the NAS allows to write to the shared folder.

You can apply the configuration using one of the following methods.

Method 1: Configure Using PowerShell (Recommended)

Open PowerShell as an Administrator.
Launch PowerShell with administrative privileges.

Run the following commands to map the anonymous UID and GID to 0, which corresponds to the QNAP root user.

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name AnonymousUid -Value 0 -PropertyType DWord

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name AnonymousGid -Value 0 -PropertyType DWord

Run the following command to restart Client for NFS or reboot the system to apply the changes:
```
nfsadmin client restart
```
Tip
Alternatively, you can restart the Windows Server.

Method 2: Configure Using the Windows Registry

Press Win + R.
Type regedit.
Press Enter.

Navigate to the following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

Go to Edit > New, and then click DWORD (32-bit) Value.
Create the following two DWORD (32-bit) values inside the default folder:
- AnonymousUid = 0
- AnonymousGid = 0
Apply the changes by restarting the NFS client:
```
nfsadmin client restart
```
Tip
Alternatively, you can restart the Windows Server.

Important

Mapping the UID and GID to 0 allows Client for NFS to access the NAS as the root user. Ensure that the NAS shared folder grants write permissions to this identity.
Apply these settings on each Windows Server that accesses the NFS share.
This applies to all Windows versions that support the Client for NFS feature.
For environments that require fine-grained permission control or NFSv4 ACL support, Windows Server acting as an NFS client is not supported.

Produits applicables

All QNAP NAS series
Windows Server (any supported version)

Scénario

Un utilisateur accède à un dossier partagé NAS QNAP via les services de fichiers réseau (NFS) depuis un Windows Server exécutant une version prise en charge. Lors de la copie d'un fichier avec le même nom, Windows affiche le Remplacer ou ignorer les fichiers message, indiquant qu'un fichier existant est présent sur le NAS.

Cependant, après avoir sélectionné Remplacer le fichier dans la destination, l'opération échoue avec une erreur d'accès refusé ou de permission, empêchant le fichier d'être écrasé ou mis à jour.

Cause principale

Ce comportement est une limitation connue de la fonctionnalité Client pour NFS dans Windows Server et est indépendant de la configuration du NAS. Le même comportement est observé sur toutes les versions de Windows Server prises en charge qui incluent Client pour NFS.

Client pour NFS prend en charge uniquement NFSv2 et NFSv3 et ne prend pas en charge les ACL NFSv4. En conséquence, il ne peut pas négocier ou modifier les ACL POSIX sur NFS.
Par défaut, Client pour NFS accède aux partages NFS en utilisant un UID et un GID anonymes. Si le NAS n'accorde pas de permissions d'écriture à cette identité anonyme, les opérations d'écriture échouent.
L'accès est refusé à moins que l'UID et le GID anonymes ne soient explicitement mappés à un UID et un GID que le NAS reconnaît et autorise à écrire dans le dossier partagé, indépendamment des permissions d'écriture configurées du dossier partagé.

Note

Ces paramètres doivent être configurés sur le Windows Server.

Solution

Pour résoudre ce problème, mappez l'utilisateur NFS anonyme sur le Windows Server à un UID et un GID que le NAS autorise à écrire dans le dossier partagé.

Vous pouvez appliquer la configuration en utilisant l'une des méthodes suivantes.

Méthode 1 : Configurer avec PowerShell (Recommandé)

Ouvrez PowerShell en tant que administrateur.
Lancez PowerShell avec des privilèges administratifs.

Exécutez les commandes suivantes pour mapper l'UID et le GID anonymes à 0, qui correspond à l'utilisateur root de QNAP.

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name AnonymousUid -Value 0 -PropertyType DWord

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name AnonymousGid -Value 0 -PropertyType DWord

Exécutez la commande suivante pour redémarrer Client pour NFS ou redémarrer le système pour appliquer les modifications :
```
nfsadmin client restart
```
Conseil
Alternativement, vous pouvez redémarrer le Windows Server.

Méthode 2 : Configurer avec le registre Windows

Appuyez sur Win + R.
Type regedit.
Appuyez sur Entrée.

Accédez au chemin de registre suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

Allez à Éditer > N ouveau, puis cliquez sur Valeur DWORD (32 bits).
Créez les deux valeurs DWORD (32 bits) suivantes dans le dossier par défaut :
- AnonymousUid = 0
- AnonymousGid = 0
Appliquez les modifications en redémarrant le client NFS :
```
nfsadmin client restart
```
Conseil
Alternativement, vous pouvez redémarrer le serveur Windows.

Important

Mapper l'UID et le GID à 0 permet au Client pour NFS d'accéder au NAS en tant qu'utilisateur root. Assurez-vous que le dossier partagé du NAS accorde des permissions d'écriture à cette identité.
Appliquez ces paramètres sur chaque serveur Windows qui accède au partage NFS.
Cela s'applique à toutes les versions de Windows qui prennent en charge la fonctionnalité Client pour NFS.
Pour les environnements nécessitant un contrôle de permission granulaire ou la prise en charge des ACL NFSv4, le serveur Windows agissant en tant que client NFS n'est pas pris en charge.

Lecture complémentaire

Vue d'ensemble de NFS sur Windows Server

Est-ce que cet article a été utile ?

Oui. Non.

Pour obtenir de l'aide supplémentaire, posez votre question aux autres utilisateurs et aux experts QNAP dans la communauté. Accéder à la communauté QNAP

Veuillez nous indiquer comment améliorer cet article :

Il manque des informations importantes dans l’article
Les solutions de l’article ne fonctionnent pas
L’article est trop compliqué
L’article contient des informations inexactes
L’article est désuet

Si vous souhaitez fournir un commentaire supplémentaire, veuillez l’inclure ci-dessous.

Applicable Products

Scenario

Root Cause

Solution

Method 1: Configure Using PowerShell (Recommended)

Method 2: Configure Using the Windows Registry

Further Reading

Produits applicables

Scénario

Cause principale

Solution

Méthode 1 : Configurer avec PowerShell (Recommandé)

Méthode 2 : Configurer avec le registre Windows

Lecture complémentaire