Unfortunately, Set-NaNfsExport will replace the permissions, and there is nothing to add permisions built in to the toolkit. It's also not trivial because the input to Set-NaNfsExport & Add-NaNfsExport can't handle all of the permutations that Get-NaNfsExport can return (allow vs. deny, sys vs. user, multiple levels, etc). But if you are creating all of your NFS exports with powershell (or you are using very simple one rule exports) then we can get pretty close.
*WARNING* this example could break existing exports if they are not configured by the toolkit.
Here's a very ugly function that will get the rules in a format that can be used by Set-NaNfsExport and eliminate rules that are not compatible:
#Expects the NFS Export info returned by Get-NaNfsExport
#Returns output that can be passed directly to Set-NaNfsExport
function getSimpleNfsExport ($export) {
$exportParams = @{
Path = $export.Pathname;
ActualPath = $export.ActualPathname;
Persistent = $false;
ReadOnly = @($export.SecurityRules[0].ReadOnly | ?{$_} |
% { if ($_.AllHosts) {"all-hosts"} else {$_.Name} });
ReadWrite = @($export.SecurityRules[0].ReadWrite | ?{$_} |
% { if ($_.AllHosts) {"all-hosts"} else {$_.Name} });
Root = @($export.SecurityRules[0].Root | ?{$_} |
% { if ($_.AllHosts) {"all-hosts"} else {$_.Name} });
NoSuid = $export.SecurityRules[0].NoSuid -eq $true;
Anon = $export.SecurityRules[0].Anon;
SecurityFlavors = $export.SecurityRules[0].SecFlavor[0].Flavor;
}
return $exportParams
}
Once you have that loaded or in your script you can do something like this:
PS C:\> $params = getSimpleNfsExport (Get-NaNfsExport /vol/testvol)
PS C:\> $params.ReadOnly += "10.61.169.80"
PS C:\> Set-NaNfsExport @params
PS C:\> getSimpleNfsExport (Get-NaNfsExport /vol/testvol)
Name Value
---- -----
ReadWrite {all-hosts}
ReadOnly {10.61.169.3, 10.16.169.4, 10.61.169.80}
Path /vol/testvol
NoSuid False
Anon
Persistent False
ActualPath
Root {10.61.169.76}
SecurityFlavors sys
