I for one would like to see your whole fstab entry (sanitized as needed) -
would be a nice reference for historical purposes :)
Blake
On Jun 29, 2015, at 10:15 PM, Patrick O'Sullivan <[email protected]> wrote:
The end story for me is that actually everything is working fine! I had added some extra
commentary in my last email, but passing "-o sec=sys" to the mount command in
the lx zone made things work.
On Monday, June 29, 2015, Jerry Jelinek <[email protected]> wrote:
Patrick,
Although NFS mounting has worked in some cases, we do have a couple of open
bugs for NFS mounting (OS-4440 and OS-4331). These might actually be
duplicates. Unfortunately I haven't had a chance to spend any time on these yet
so I don't have any solution for you, but I will add your info to one of the
bugs. Thanks for doing the research on this, hopefully once I get time to look
at this it will be clear what needs to be fixed.
Sorry I don't have any better news for you,
Jerry
On Sat, Jun 27, 2015 at 10:01 PM, Patrick O'Sullivan <[email protected]>
wrote:
This bothered me enough to keep looking. :-)
I kept looking at packet captures, and what stood out is the fact that
the broken interactions showed AUTH_NULL for the credential flavor,
which was the cause of the NFS3ERR_ACCES error. Quick fix: make sure
the mount command from the lx zone has "-o sec=sys" in it. Packet
captures now reflect AUTH_UNIX, with the appropriate uid/gid for
credentials.
Couple of things to note:
1. Debugging the NFS server in Linux absolutely sucks. Even cranking
up the debug level to everything (rpcdebug -m nfsd -s all) gets you no
useful information for this sort of issue. The NFS3ERR_ACCES error
seen in packet captures? Nope, not there.
2. You can't easily disable NFSv4 server side. Sure, there's this line
in /etc/default/nfs-kernel-server:
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
Except, it doesn't work:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738063
Thanks Joshua for your comments which helped me look at some of the
details here a bit more closely.
On Fri, Jun 26, 2015 at 11:26 PM, Patrick O'Sullivan
<[email protected]> wrote:
So I've looked at some packet captures and things are a bit
interesting. The working mount from the global zone is all v4. The
broken session from the lx zone starts in v4 but then switches to v3.
At some point, the server returns NFS3ERR_ACCES in response to the
ACCESS call from the lx zone client. Going to see if some additional
debugging flags on the server shed some light.
On Fri, Jun 26, 2015 at 5:58 PM, Joshua M. Clulow <[email protected]> wrote:
Hi,
On 26 June 2015 at 12:08, Patrick O'Sullivan <[email protected]> wrote:
I have an Ubuntu 14.04 server running on bare metal with the following
line in /etc/exports:
I can also mount it from a global zone on a box running SmartOS build
20150612T210440Z:
However, trying to access it from an Ubuntu 14.04 lx zone
(5a0145ee-15c4-11e5-9c49-ef53e8760a7e), I get permission errors when
accessing the directory, though it appears to mount fine:
Are you using NFSv3 or NFSv4 here? NFSv3 with AUTH_SYS is all uid/gid
numbers on the wire. In contrast, NFSv4 sends user/group name
_strings_ for some parts of the protocol, and AUTH_SYS-style numbers
for other parts. The strings can involve an NFSv4 domain name, which
under some circumstances needs to be in sync, and on an illumos system
may require "nfsmapid" to be running within the mounting zone.
Can you try forcing the mount (or the server) to use NFSv3 and see if it helps?
Cheers.
--
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org
http://www.listbox.com
http://www.listbox.com
smartos-discuss | Archives | Modify Your Subscription
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
