# NFSv4 issue read-only versu sread-write

## toralf

I didn't get it, with the following definitions at the NFSv4 server 

```
n22 ~ # cat /etc/exports

# /etc/exports: NFS file systems being exported.  See exports(5).

/                       192.168.0.0/16(ro,no_subtree_check,fsid=0)

/usr/portage            192.168.0.0/16(rw,no_subtree_check,insecure,async,no_root_squash)

/var/lib/distfiles      192.168.0.0/16(rw,no_subtree_check,insecure,async,no_root_squash)

```

I can at the NFS client write into /usr/portage but not into /var/lib/distfiles. If I change the "ro" into "rw" for /, then it works. At the client side I do for both directories the same permissions :

```
n22:/usr/portage        /usr/portage            nfs     auto,bg,intr,soft,nfsvers=4

n22:/var/lib/distfiles  /var/lib/distfiles      nfs     auto,bg,intr,soft,nfsvers=4

```

The different at the server is however that /usr/portage is defined in /etc/fstab as :

```
/var/lib/portage.fs     /usr/portage            btrfs   auto,noatime,compress=lzo
```

I tried a lot with ownership and permissions for both source directories, but nothing helped till now:

```
n22 ~ # ls -ld /usr/portage/ /var/lib/distfiles/

drwxr-xr-x 1 root    root     3386 Aug 17 19:24 /usr/portage/

drwxrwsrwx 4 portage portage 65536 Aug 17 19:29 /var/lib/distfiles/
```

Any hints ?

UpdateHhm, just removed the fsid line and it works now .../Update

----------

## krinn

What you are doing there is exporting ALL your root filesystem to any clients !!! That's what anyone could easy tell : a huge security hole!!!

Ok, i'll do a real example, as i'm getting a bit tired explaining this to everyone.

the server nfs4 directory state with fsid=0 is what i will called the "nfsroot".

other export directories are attach to this one and are subdirs of it. If you need export a directory that isn't a subdir of nfsroot, you must bind them.

a real /etc/exports for nfsv4

```
/export 192.168.0.0/16(ro,no_subtree_check,fsid=0)     <------- so this is your nfsroot directory

/export/myportage            192.168.0.0/16(rw,no_subtree_check,insecure,async,no_root_squash) <--- it's a subdir of /export

/export/mydistfiles      192.168.0.0/16(rw,no_subtree_check,insecure,sync,no_root_squash)  <-- again subdir of /export

```

ps: i use myportage and mydistfiles to help everyone see what directory we are speaking of and help see if the directory name is from the nfs server or from your real filesystem

the /etc/fstab part for the binding that will help you

```
/usr/portage     /export/myportage    none   bind

/var/lib/distfiles   /export/mydistfiles none bind

```

Now how nfsclients see and mount those share

nfsclientv4 will see your exported directories as :

/ (the nfsroot)

/myportage (because it's relative to your nfsroot, so it's not /export/myportage but /myportage)

/mydistfiles

But nfsv4 server can also export to nfsv3 clients, they will see and use them like with nfsv3 server.

Now if you want nfsclient v4 to mount distfiles as nfsv4 share :

mount -t nfs server:/mydistfiles /mnt/mountpoint     <--- server: / (nfsroot) + mydistfiles

Any try to mount -t nfs server:/export/mydistfiles /mnt/mountpoint should return the "directory doesn't exist" error because there is no subdirectory export/mydistfiles attach to your nfsroot (got it? You have in your FS the directory /export/mydistfiles but the server is looking as its own virtual FS and there's no /export/mydistfiles in it, it see it as /mydistfiles)

Alas or happy for us, nfs-utils try to guess what we are doing and will retry as nfsv3 mount when it fail. So it will works, but it will be mount as a nfsv3 share and not as nfsv4

mount -t nfs4 server:/export/mydistfiles /mnt/mountpoint ; again "directory doesn't exist" error, but this time we specially pass the -t nfs4 so nfs-utils will not try to mount it as nfsv3 and bail out with the proper error "reason given by server: No such file or directory"

Telling your server you want mount it as nfsv3 is done with :

mount -t nfs -o nfsvers=3,vers=3 server:/export/mydistfiles /mnt/mountpoint  <--- old style server:/export/distfiles

----------

## toralf

Thx for the long answer, but I think that 

```
/                       192.168.0.0/16(rw,no_subtree_check,fsid=0)
```

should be fully sufficient for this test desktop system having just KVM clients in 192.168.x.x, or ?

Nevertheless I do argue, that the example in the origin of this email might point a bug either in NFSv4 and the no_all_squash options or it the reail culprit is that i was allowd to write into /usr/portage (uin my example) just because that is a bind mount to a BTRFS file system located in a file.

Will take a closer look onto that ....

----------

