I'm having trouble getting a Solaris 11.0 server to restrict access to an NFS share to a single client system.

I have roughly the following value for the share property of a tank/mail ZFS filesystem:

name=mail,path=/tank/mail,prot=nfs,none=*,[email protected],sec=sys

I cannot mount the share on the client (running Solaris 11.3) at I attempt like so:

mount -F nfs keisha:/tank/mail /tmp/mnt

and get the following error:

nfs mount: mount: /tmp/mnt: Permission denied

If I remove none=* then the client mounts fine. However, it is my understanding that doing so will allow access to clients at any address, which I want to prevent (and yes, I'm aware that it may be possible to spoof the address, but prefer to add whatever hoops I can.)

I have tried reversing the order of none and rw, and this changes nothing. I've tried [email protected]/32 and that doesn't work either.

I've tried opening it up to the whole subnet with [email protected]/16 and even that doesn't work. I've also double-checked that I have the client's address right. The client can't be using IPv6 to access the server, as the server's DNS entry is only IPv4 and I'm accessing it by name.

Why does restricting the client addresses prevent access even from a client at an explicitly allowed address? How do I fix this?

  • 1
    If you only define one client, there should be no access from any other one. And by giving the complete IP, you do not need the '@'.
    – ridgy
    Commented Jun 28, 2017 at 14:22
  • @ridgy I'll try taking out the '@', but the man page does indicate it even for a single IP. I think it's to signal that it's not a hostname. could be a valid hostname if someone gets crazy enough to pay $185,000 for .43 and ICANN gets crazy enough to approve. :) Commented Jun 28, 2017 at 21:19

2 Answers 2


The comment by ridgy hinted at the answer. What was needed was to remove none, leaving:

name=mail,path=/tank/mail,prot=nfs,[email protected],sec=sys

(It might be possible to omit the @ but the documentation calls for it so I figured it better to leave it in, in case the interpretation becomes more strict in future.)

This is a case of poor documentation. The man page states (emphasis mine):

Access is disallowed to all clients. The ro or rw options can override none.

Access is not allowed to any client that matches the access list. The exception is when the access list is an asterisk (*), in which case ro or rw can override none.

Not only does this very explicitly indicate that my client at should have gained access even with none (which it did not,) it also implies that you actually need none in order to avoid clients not listed in rw getting at least some kind of access, because otherwise, why would the override exception for none=* have even (supposedly) been implemented? It would be redundant!

I didn't have any other NFS clients handy to test, so I changed the IP number of my client and confirmed that, indeed, none is not required in order for clients not otherwise listed to be denied access. Just to be sure, I added ro as a test, and my client at a different address could then read but not write.

Though this seems to be the solution, I'm not happy with it, because the documentation implies that what I'm doing is leaving it wide open, and indeed I might be doing just that in a future version that corrects itself to obey the intentions implied by the documentation. (At least I have external firewalls.)

  • Did you see this part of the man page for share_nfs: The list is searched sequentially until a match is found that either grants or denies access I suspect that if you had reversed your list to [email protected],none=* it may have worked as you intended. Commented Jun 29, 2017 at 19:13
  • 1
    The documentation indeed is not consistent. Especially for ZFS, there is docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html, which refers to docs.oracle.com/cd/E23824_01/html/821-1462/… somewhere. But at the options section, none= is only specified for smb, not for nfs. This seems to be sort of "Try and Error".
    – ridgy
    Commented Jun 29, 2017 at 21:41
  • @AndrewHenle I did see that statement, which by context applies to the contents of the access list given to the rw, ro, or none option, as opposed to the order of those options themselves. Nevertheless I did try reversing the options as in your example and the outcome was the same. Commented Jun 30, 2017 at 10:46
  • @Kevin Well, it's either a bug or you've just been welcomed to Solaris documentation. If it's not a bug, the behavior you're seeing almost certainly is documented somewhere in the documentation, but it's likely to be a footnote, obscure example, or a parenthetical expression on a man page at best peripherally related to sharing over NFS. The only way to find it is to know where it is in the first place, or open a support ticket and be told where it's documented. The newer, Oracle-era additions to Solaris also don't seem to be as rigorously documented as the Sun-legacy parts. Commented Jun 30, 2017 at 12:10
  • @AndrewHenle Yup, definitely have been experiencing that welcome! :) Commented Jul 5, 2017 at 19:14

Looks like ridgy answered your question, if it's shared to just one host. If you have multiple, using a semi-colon, or creating a netgroup could be used.

If you need/want additional blocking, you could look into using ipfilters or the Solaris Firewall derived from OpenBSD PF (pkg:/network/firewall).

  • Feel free to incorporate the comments into your answer, as comments can be deleted, making this answer much less useful.
    – Jeff Schaller
    Commented Jun 28, 2017 at 19:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .