2

Situation:

We are using a Nexenta appliance for NFS file serving (nfs v3). We are sharing a path for anonymous read/write access.

We have a Linux host we would like to mount that exported read/write share and also allow anonymous read/write access to that mounted share on that client machine. Unfortunately, what ends up happening is that root can write to the share, but unprivileged users cannot.

Using the following methods to mount the share:

# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw

We have specific user we intend to use for the anonymous usage on the share. So I attempted to mount the volume as that user:

# su - shared_user
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw
mount.nfs: an incorrect mount option was specified

Went and did some reading: http://nfs.sourceforge.net/nfs-howto/ar01s06.html.

Decided to give the following a try which give the proceeding errors when attempting to mount:

# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path 
mount.nfs: an incorrect mount option was specified
# mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path  # for grins and giggles.
mount.nfs: an incorrect mount option was specified
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash
mount.nfs: an incorrect mount option was specified

Am I just SOL or is there something I'm fundamentally missing here? Is this a holy grail I'm attempting to find? I have never heavily used NFS so I'm at a bit of a loss here, now. TIA!

Jim
  • 335
  • 1
  • 3
  • 13

1 Answers1

2

OK. Figured it out. First, the version of Nexenta I'm using is 3.1.3.5. Nexenta is an OpenSolaris based appliance that vends block storage via CIFS, NFS, Rsync, WebDAV, and FTP. In our case, we're using it solely for NFS (v3 is default. v4 is not available for this version).

So, tl;dr; on the Nexenta side:

Login to the Nexenta as root:

$ ssh root@xx.xx.xx.xx
Password:
Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx
nmc@nex01:/$ option expert_mode = 1

nmc@nex01:/$ !bash
You are about to enter the Unix ("raw") shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute?  Yes

root@nex01:/volumes#
root@nex01:/volumes# grep nfs /etc/passwd
nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh

Note the numbers after the first x:#####:##### -- these are the uid and gid respectively.

on the client side: create user: 

# groupadd nfs -g 60001 && useradd nfs -g 60001  ## untested. I did it the long way through natural process of elimination, so be careful here.

All good now.

Mount up the volume and verify that your newly created nfs user can write to the NFS volume.

Long version:

I had the NFS side set up correctly, as far as I can tell. The documentation was helpful, but in some ways it was only divvying breadcrumbs.

"Allow anonymous access to this share. Shared top-level directory will be granted read-write access for anonymous user 'nfs'. If recursive share mode is set to true, this property is propagated to existing sub-folders. Note that anonymous read/write access is not inheritable - anonymous access to future sub-folders will not be allowed until explicitly requested. The anonymous user name is 'nfs'."

My shared_user eventually became "nfs", which was still failed (see OP). I decided, because I thought it was a long shot, to make my UID on the client side match that of the UID for 'nfs' on the appliance. I had to log in to the appliance, start a bash shell, and then run the id command to obtain the UID, which in my case was 60001.

On the client, I altered the nfs user to match the UID on the appliance. Apparently the appliance does require the UID/GID to match its own for this to work. I figured the NFS server would ignore that. This was the apparently the crux of the issue.

Now, the appliance uses nfs:nobody for user:group. nobody on the client (Linux) side is a different UID, and changing the UID for nobody would be a little bit more involved and I don't know what I could inadvertently affect by changing that groupid, so I didn't touch it. The nfs user on the client machine was non-existent before I started mucking around, so there was no risk of breaking anything. There is an nfsnobody on the client side. I didn't test using it and I'm pretty sure it wouldn't have worked since the documentation is specific about the user id.

I should also state here that the appliance was specifically set to use sysauth for authentication. Using auth=none was not an option as NFSv3 doesn't seem to like it. :)

that is all.

Jim
  • 335
  • 1
  • 3
  • 13