Allow "Auxiliary Parameters" for NFS shares

This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.

Thanks for the suggestion but this will not be implemented.

if you have specific features/use cases that could be considered feel free to add new suggestions tickets and these will be evaluated.

For historical reasons there are auxiliary parameters for other services. Thats not something we agree on doing anymore.

The request is mainly based on consistency. SMB, SSH, and Rsync allow additional auxiliary parameters. (With all the same risks of allowing users to enter their own custom parameters.)

“So the request is to add an auxiliary parameters field so that you can set a parameter that can lead to data loss in case of unclean server restart?”

If using “async” leads to dataloss, that’s on the user. Perhaps they want to increase write performance and fully know the implications of using “async” as an export option. After all, they went out of there way to explicitly enter this custom parameter. (This is no different than using discouraged auxiliary parameters for any other service. It’s not unique to NFS.)

A disclaimer and warning can be included for all parts of the GUI that allow the user to enter their own auxiliary parameters.

(I really hope that this doesn’t trigger the development team to decide to remove all auxiliary parameter fields from every service in the GUI. That’s not the reason for this improvement request.)

fsid is derived from device id, so this is a non-issue (unless you can specifically reproduce issues with stale file handles on NFS server restarts).

So the request is to add an auxiliary parameters field so that you can set a parameter that can lead to data loss in case of unclean server restart?

“Generally speaking, auxiliary parameters have been a significant source of pain for SMB side of things. More often then not, users do significant foot-shooting with them.”

I understand, and the risks involved apply equally to SMB and NFS. Currently, SMB shares allow “Auxiliary Parameters” without any such disclaimer or warning. So does Rsync and SSH. So why not NFS shares?

Or from another approach: Why not allow “Auxiliary Parameters” for both SMB and NFS shares, but also include a warning or disclaimer?

“Can you please elaborate on what you mean by “for the sake of reliability” and what fine-tunings are actually needed?”

One example is to enforce “static” fsid’s from the server side.

• use the fsid=<unique number> on the server side in /etc/exports. This creates a static unique identifier for the export, so you won't get a "Stale NFS File Handle" error on the client if the server is restarted or goes offline. These ID numbers must be unique and be greater than 1, since 1 is used by NFSv4 as the root export.

Another example is to export as “async”. Yes, this introduces a risk in order to boost performance. But once again, a user who explicitly uses “Auxiliary Parameters” is undertaking their own risks. This can be further understood with a disclaimer or warning.

For example, if a use reads the following warnings, it’s their own fault if something bad happens. But why entirely cut off someone from applying their own parameters? It’s allowed for Rsync. It’s allowed for SMB. It’s allowed for SSH. Why is NFS arbitrarily restricted? This is why I think it should allow NFS “Auxiliary Parameters”, with a disclaimer that can warn the user.

“Unsupported feature”, “Use at your own risk”, “Highly discouraged”, “This can lead to data loss or corruption”, etc, etc, etc.