# ZFS on NFS, permissions and export values



## blink (Dec 20, 2009)

I can't seem to mount a ZFS filesystem, shared with NFS to be read/write accessible.

When I mount the drive from a gentoo linux client, it shows up fine and says it's mounted rw, but doesn't actually let me make any changes.

Client = 192.168.1.2
Server = 192.168.1.196


On the server

```
# zfs set sharenfs=on tank/storage
# showmount -e
Exports list on localhost:
/tank/storage                 Everyone

# cat /etc/zfs/exports
# !!! DO NOT EDIT THIS FILE MANUALLY !!!
/tank/storage
```

On the client

```
# mount 192.168.1.196:/tank/storage /mnt/storage
```

back on the server

```
# tail -n 1 /var/log/messages
Dec 20 16:25:07 tobias mountd[840]: mount request denied from 192.168.1.2 for /tank/storage
```

I'm not to sure on what options to pass zfs on the server side, nfsoptions=rw causes errors in /var/log/messages like this when the same mount command is issued on the client:

```
Dec 20 16:37:53 tobias mountd[840]: can't get address info for host rw
Dec 20 16:37:53 tobias mountd[840]: bad host rw, skipping
Dec 20 16:37:53 tobias mountd[840]: bad exports list line /tank/storage   rw
```

`zfs set sharenfs=192.168.1.2 tank/storage` allows the client to mount it, but still gives errors when trying to take action on the filesystem:
Client:

```
# touch /mnt/storage/test
touch: cannot touch `/mnt/storage/test': Permission denied
# mount |grep 192
192.168.1.196:/tank/storage on /mnt/storage type nfs (rw,addr=192.168.1.196)
```

Server:

```
# showmount -e
Exports list on localhost:
/tank/storage                     192.168.1.2
```

Not sure how to get this usable by root, let alone a normal user...


----------



## gordon@ (Dec 20, 2009)

By default, NFS squashes root account requests to be equivalent as being from the 'nobody' user. To test this theory, on your server, create a directory with global permissions:

```
# mkdir /tank/storage/foobar
# chmod 1777 /tank/storage/foobar
```

Then go to the client and try it out:

```
# cd /mnt/storage/foobar
# touch testfile
```

If that works, then do `% ls -l` on the testfile and see who the permissions are.

For information about root squashing, check out the documentation for the exports(5) man page. In particular, look at the -maproot option.


----------



## blink (Dec 20, 2009)

I created the test file, and it's permissions were blink:wheel on the server and blink:root on the client (blink uid=1000 and wheel/root =0)

Using that logic, I create a directory called Music owned by blink:wheel, but on the client it shows up as root:root over NFS.

Figuring I can use the option you told me about, I set the share using this on the server, allowing the sharenfs to be applied to tank/storage/Music by inheritance:

```
# zfs create tank/storage/Music
# zfs set sharenfs='-mapall=1000:1000 -network 192.168.1.0/24' tank/storage
# chown blink:blink tank/storage/Music

# showmount -e
Exports list on localhost:
/tank/storage/Music                192.168.1.0 
/tank/storage                      192.168.1.0 
# ls -la /tank/storage
total 15
drwxr-xr-x  3 root   wheel     3B Dec 21 06:57 .
drwxr-xr-x  3 root   wheel     3B Dec 21 06:58 ..
drwxr-xr-x  2 blink  blink     2B Dec 21 06:57 Music
# exit
$ touch /tank/storage/Music/test.touch.as.blink
$ ls -al /tank/storage/Music
total 6
drwxr-xr-x  2 blink  blink  3 Dec 21 07:06 .
drwxr-xr-x  3 root   wheel  3 Dec 21 06:57 ..
-rw-r--r--  1 blink  blink  0 Dec 21 07:06 test.touch.as.blink
```

I mount /tank/storage on the server to /mnt/storage on the client

this is what the client sees now

```
$ ls -la /mnt/storage
total 9
drwxr-xr-x 3 root root    3 2009-12-21 06:57 .
drwxr-xr-x 5 root root 4096 2009-12-13 09:44 ..
drwxr-xr-x 2 root root    2 2009-12-21 06:57 Music
$ ls -la /mnt/storage/Music
total 5
drwxr-xr-x 2 root root 2 2009-12-21 06:57 .
drwxr-xr-x 3 root root 3 2009-12-21 06:57 ..
```

The file isn't there over NFS. Is there something about ZFS exports that causes all of this confusion? Since storage and Music are both filesystems, does inheritance get blocked crossing that boundary, and if so does that mean that mounting on the last available exported folder of the filesystem would negate it?

Is it possible to just use the mounted file system read/write as a normal user at all? If it works with 1777 perms inside the foobar folder, I don't see why it doesn't when I reduce the permissions to something appropriate. or is the sticky bit somehow needed still? After having read the handbook on this, the ZFS documentation and the man pages for mountd, exports and id, I'm not really feeling any closer to an answer.


----------



## gordon@ (Dec 20, 2009)

That's an odd one. Unfortunately, I don't have any experience with ZFS so I can't really help you there. Seems like there is some cache that is causing you to see the problem you are having. I don't have a whole lot of advice for you otherwise.


----------



## blink (Dec 21, 2009)

Is this better suited to another forum or should I just set the folders 1777 and be done with it? Maybe lock it down with kerberos to make up for the fact it's wide open...


----------



## blink (Dec 21, 2009)

Seems to allow me to get the inheritance I was talking about by using the -alldirs option.  I still can't find clear documentation on what that does.


----------



## blink (Dec 21, 2009)

Ok, sorry for the triple post but I can't edit posts.

The filesystem is usable by the user in the following scenario.
Run on the server:

```
# zfs sharenfs='maproot=root -alldirs -network 192.168.1.0 -mask 255.255.255.0' storage/Music
# ls -la /storage/Music
total 10
drwxr-xr-x  2 root  wheel  2 Dec 21 17:46 .
drwxr-xr-x  5 root  wheel  5 Dec 21 17:46 .
```

On the client, mount, then chown to the user that will be doing the read/writing

```
# chown blink:blink /mnt/storage/Music
$ touch /mnt/storage/Music/test
$ ll -a /mnt/storage/Music/test
total 5.5K
drwxr-xr-x 2 blink blink 3 2009-12-21 17:59 .
drwxr-xr-x 5 root  root  6 2009-12-21 17:59 ..
-rw-r--r-- 1 blink blink 0 2009-12-21 17:59 test
```

But all of this breaks when I set the server to maproot=blink and chown Music to blink; it becomes read only even as root on the client.  Is this a bug with ZFS? At least I know there's no caching, it's all being updated as I issue the commands, definitely permissions related with freebsd's NFS or ZFS.


----------



## wintesa (Mar 6, 2010)

Hi,

I have the same problem that when I share a directory hierarchy populated at various depths with various numbers of files; the client cannot see them. However if I mount NFS at a level lower down it can be seen fine.

Its kind of a weird problem if anyone has any solutions let me know!:f


----------

