# [RESOLVED] NFS mount implicitly squashed?

## knifeyspoony

Hi,

Our problem arose when we upgraded to a new version of Wine to gain compatibility with a Windows program. The new version checks that its working directory is owned by the executing user. If it isn't, then Wine refuses to run.

We mount home directories over NFS. When we export, we squash root only -- we don't squash all. Yet from the clients' points of view, users' home directories are always owned by nobody/nogroup (65534/65534). I believe nothing in our exports or fstabs would cause that.

```
#Client /etc/fstab line

192.168.1.1:/   /FileServer     nfs4    proto=tcp,sec=sys,hard,intr,rsize=3276800
```

```
#Server /etc/exports

/home/nfs-export/       192.168.1.0/24(rw,fsid=0,root_squash,sync)
```

My only idea: Because /home/nfs-export is root-owned on the server filesystem, all its subdirectories look root-owned to the client upon export. (The home directory that the client mounts is actually /home/nfs-export/Users/username). So does the client's fstab need explicit, nested mounts of each individual home directory? Or how else should I proceed?Last edited by knifeyspoony on Mon Feb 22, 2010 6:06 pm; edited 1 time in total

----------

## Hu

What is the output of ls -la ~ for one of the affected users?

----------

## krinn

you're using nfsv4

for nfsv4 you need a default root directory and then, you can add subdirectories in it to share them (and alter their access, rights...)

so you need at min 2 entries in /etc/exports like

/home/nfs-export <- will be use as your root nfst, this can also be change but rules are special for that one

/home/nfs-export/clients <- now you can pass things to it as 192.168.1.0/24(rw...blahblah) for your clients.

reread nfsv4 manual.

----------

## knifeyspoony

 *Hu wrote:*   

> What is the output of ls -la ~ for one of the affected users?

 

server:~# ls -lad ~tina

drwx--S--- 28 tina People 4096 2009-12-03 09:32 /home/nfs-export/FileServer/Users/tina

server:~$ ls -ladn ~tina

drwx--S--- 28 1053 9000 4096 2009-12-03 09:32 /home/nfs-export/FileServer/Users/tina

client:~$ ls -lad ~tina

drwx--S--- 28 nobody nogroup 4096 2009-12-03 09:32 /FileServer/Users/tina

client:~$ ls -ladn ~tina

drwx--S--- 28 65534 65534 4096 2009-12-03 09:32 /FileServer/Users/tina

Ownership is similarly mangled for each file inside the directory.

 *krinn wrote:*   

> for nfsv4 you need a default root directory and then, you can add subdirectories in it to share them

 

Thank you, though I couldn't find any manual content under nfs, nfsd, exports, or exportfs to tell me that what you describe is mandatory or even recommended. The exports man page has an example conf file with that kind of structure, but that's it.

I still proceeded with your suggestion. Unfortunately, what I changed (new /etc/exports printed below) did not help us.

/home/nfs-export                server(rw,crossmnt)

/home/nfs-export/FileServer     192.168.1.0/24(rw,fsid=0,root_squash,sync)

----------

## krinn

 *knifeyspoony wrote:*   

> to tell me that what you describe is mandatory or even recommended.

 

doc: http://www.ietf.org/rfc/rfc3530.txt (see section 7)

example: http://www.brennan.id.au/19-Network_File_System.html#nfs4 (and glad for you, the example even export /home)

----------

## knifeyspoony

krinn, did I do something incorrectly? My new exports didn't fix it.

----------

## krinn

do on server

```
exportfs -v
```

the fsid=0 must be your server root, so /home/nfs-export server(fsid=0) but not /home../FileServer

----------

## knifeyspoony

I moved fsid=0 to the "root" line and rebooted and server and clients. None of the users could mount their home directories upon login, so I had to change it back.

----------

## knifeyspoony

The serendipity of an Xorg crash led me to syslog, which contained messages of this form:

```
nss_getpwnam: name '0' does not map into domain 'localdomain'
```

There were two problems:

1. On the NFS server, /etc/hostname did not contain the FQDN, just the local hostname.

2. This particular client had an unconfigured /etc/idmapd.conf. It had Domain = localdomain instead of Domain = FQDN-minus-hostname.

Thanks,

ks

----------

## depontius

Pardon me if I'm getting too simple here.  Are you running idmapd on both client and server, with matching configurations?

I run nfsv4 on my home server, exporting /home to my client machines.  I have no troubles whatsoever with ownership of any of the directories, and I do have root squashed, by the way.  But if there's anything wrong with idmapd, either misconfiguration or not running, you'll get exactly what you describe.  Plus idmapd is not a normal feature of nfsv3 - it's specific to nfsv4, and therefore not "normal."

If this rings a bell, I can look more at my home configuration later this evening or tomorrow evening to help.  I also had a time a while back where idmapd didn't start right the first time, so I restarted it in rc.local.

----------

## knifeyspoony

Thank you, but the problem was resolved when I changed the server's hostname file and the idmapd.conf on those clients that needed it fixed. We are still running NFS4 with root squashed.

----------

