# [SOLVED] NFSv4 with user write permissions

## GlemSom

I've been trying to setup a nfs4 mount to share some files.

On the server my /etc/export contains this:

```
/mnt/storage    192.168.0.0/8(rw,no_root_squash,fsid=0,insecure)
```

My client's fstab this:

```
192.168.0.190:   /mnt/storage   nfs4   rw,user   0 0
```

When mounted, mount reports this:

```
192.168.0.190: on /mnt/storage type nfs4 (rw,user=root,noexec,nosuid,nodev,clientaddr=192.168.0.198,addr=192.168.0.190)
```

/mnt/storage has these permissions (seen from the client - when mounted)

```
ls -l /mnt/ | grep storage

drwxr-xr-x 6 mythtv root 32768 2009-03-21 14:54 storage
```

A file in the share:

```
ls -l /mnt/storage/a 

-rw-r--r-- 1 mythtv video 4 2009-03-21 14:49 /mnt/storage/a

```

The user mythtv can read the file, but is unable to write/delete it:

```
mythtv@sleepyIII /mnt/storage $ ls -l a; echo "some text" >> a; rm -rf a

-rw-r--r-- 1 mythtv video 4 2009-03-21 14:49 a

-su: a: Permission denied

rm: cannot remove `a': Permission denied

```

I'm using no_root_squash - so root IS able to do operations on the mount... But I would prefer if the user "mythtv" could do it aswell!.

Both machines are having rpc.idmapd running - with the default configuration file.

What have I've been missing here?Last edited by GlemSom on Tue Mar 31, 2009 6:46 pm; edited 1 time in total

----------

## richard.scott

What are your access rights on the server for /mnt/storage 

can you show:

```
# ls -al /mnt/storage
```

Also, does the server have a user called "mythtv" with the same UID/GID as on the client?

Rich

----------

## GlemSom

The accessrights for /mnt/storage is: drwxr-xr-x  6 mythtv root 32768 Mar 30 18:00 storage

The server has the same user - though NOT with the same UID.

Though, when listing the files from the client - they are reported as being owned as "mythtv"... So I guess idmapd is converting the username/UID?

----------

## richard.scott

I'd start by creating a new user with the same UID/GID on the server and client just to rule that out.

 *GlemSom wrote:*   

> So I guess idmapd is converting the username/UID?

 

Have you configured /etc/idmapd.conf?

From googling this up: http://linux.die.net/man/5/idmapd.conf - it seems you'd need something like this in /etc/idmapd.conf:

```
[Mapping]

mythtv-user mythtv

video-group video
```

but perhaps I've read that webiste page wrong?

----------

## danomac

 *GlemSom wrote:*   

> I've been trying to setup a nfs4 mount to share some files.
> 
> On the server my /etc/export contains this:
> 
> ```
> ...

 

Are you sure you're using the right netmask? /8 isn't very common, most routers use /24.

----------

## GlemSom

I tried with these mappings - but I still get the same result

```
[Mapping]

Nobody-User = nobody

Nobody-Group = nobody

mythtv-user = mythtv

mythtv-group = video
```

 :Sad: 

----------

## GlemSom

This is how it looks from the client side:

```
mythtv@sleepyIII /mnt/storage $ ls -ln a && cat /etc/passwd | grep 107; cat /etc/group | grep 27

-rw-r--r-- 1 107 27 4 2009-03-21 14:49 a

mythtv:x:107:27:added by portage for mythtv:/home/mythtv:/bin/bash

video:x:27:root,glemsom,mythtv
```

So, from the clients view - the file is owned by UID 107(this is user:mythtv), and GID is 27(this is video).

This looks as it should...

Still UID 107 does NOT have write permissions to the file  :Sad: 

I created a file on the server with these permissions:

```
ls -ln b

-rw-rw-rw- 1 102 27 0 Mar 30 21:46 b
```

Seen from the client side:

```
ls -ln b

-rw-rw-rw- 1 107 27 0 2009-03-30 21:46 b
```

NOTE: the others group has read/write permissions to this file.. so EVERYONE should be able to delete it!

But still, from the client:

```
rm b

rm: cannot remove `b': Permission denied
```

So, eventhough the file has global write permissions - my user is still not able to write/delete the file  :Sad: 

----------

## richard.scott

I've always found that things like this are due to the permissions on the server side when you can't explain things.

try:

```
# chmod -R a+rwx /mnt/storage
```

on the server... its not overly secure, but it may fix your problems.

----------

## disi

Since you have no_root_squash you can change the owner from client side. Map the share and then try to run as root

```
# chown -R mythtv:video /mnt/storage
```

I had the same trouble, if the server creates files that should be able to be changed from client side. All the nfs settings apply only on new created files via nfs not the existing or on the server created ones (UID/GUID problems). But I do not know, why you can't change the file where everyone should have access to  :Sad: 

I hope this is of any help.

----------

## richard.scott

 *GlemSom wrote:*   

> I tried with these mappings - but I still get the same result
> 
> ```
> [Mapping]
> 
> ...

 

Did you try with "video-group = video" ?

After all, the group is called video, and not mythtv

----------

## depontius

I've been running nfs4 at home for some time now, using it to export $HOME to several machines.

First, I don't like your /etc/exports.  With nfs4 you set up something like an "export root", and then your export directories are nested, frequently bind-mounted, under that.  My /etc/exports looks like this:

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

/exports       nnn.nnn.nnn.0/255.255.255.0(fsid=0,rw,sync,no_subtree_check,secure,anonuid=1000,anongid=100)

/exports/home  nnn.nnn.nnn.0/255.255.255.0(nohide,rw,sync,no_subtree_check,secure,anonuid=1000,anongid=100)
```

The first line is the "export root", and the second line is what I'm actually exporting.  The lines from /etc/fstab that are relevant to this:

```
/dev/md1                /raid1-1        ext3            data=journal,relatime,nosuid,noexec,nodev       1 2

/raid1-1/home           /exports/home   none            bind            0 0
```

So I have a raid-1 volume, and one subdirectory tree from that is bind-mounted to /exports/home, which is then exported over nfs4.

At the client side, I have this in /etc/fstab:

```
myserver.mydomain:/home          /home                   nfs4    rw,hard,intr,rsize=32768,wsize=32768,nosuid,nodev               0 0
```

Nothing special there, obviously.

Second, others have pointed out the stuff with /etc/idmapd.conf, and I have to agree that this will prevent things from working properly.  When first starting up, and occasionally during updates, I have rpc.idmapd problems, and see that I've mounted /home properly, but none of the id mapping is correct.  Then it's time to update the configs and get rpc.idmapd running right, then all is well.

But there's another step that I'd suggest first.  I have a longstanding wish to move over to central authentication with ldap/kerberos, but have never had the time and/or expertise to get the whole alphabet soup running.  However, a first key step to this is to "harmonize" /etc/passwd and /etc/group among the various machines.  It's really best if the /etc/passwd entry for "GlemSom" has the same UID, GID, etc on all machines on the LAN.  This is necessary in order to move easily to central authentication, and it makes it a heck of a lot easier to move to central file service.  I guess /etc/idmapd.conf can remap that stuff for you, but I'd sooner just user usermod/groupmod to "harmonize" the stuff.

Even with that, you still need rpc.idmapd running.  I just use /etc/idmapd.conf to establish my domain and remap the "Nobody" stuff.  (The latter can be handy so that root can look around on the nfs volume, at least a little, once it's been squashed.)  So my /etc/idmapd.conf starts with:

```
[General]

#Verbosity = 0

# The following should be set to the local NFSv4 domain name (REQUIRED)

Domain = mydomain

[Mapping]

Nobody-User = anyuser

Nobody-Group = users
```

Hope this helps...

----------

## GlemSom

Ahh, I found found my problem!  :Very Happy: 

It turns out I completly misunderstood the function of idmapd.

idmapd (called: rpc.idmapd — NFSv4 ID <-> Name Mapper) is NOT a userid mapper!

It's ONLY for mapping one user, and one group (nobody:nobody).

This is used when NOT using no_root_squash - so root get's mapped to nobody (or somebody else - defined in exports)

So, to summen up - the serverside /etc/exports ended up looking like:

```
/exports   192.168.0.0/8(rw,fsid=0,secure,no_subtree_check,async,no_root_squash)

/exports/storage   192.168.0.0/8(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
```

And client fstab:

```
192.168.0.190:storage   /mnt/storage   nfs4    rw,_netdev,auto,intr,hard,nodev,nosuid  0  0
```

And server fstab:

```
/mnt/storage   /exports/storage   none   bind   0 0
```

/etc/idmapd.conf back to original - provided by portage

And then I changed the UID to be the same on client and server.

----------

