Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a setup very similar to Dan Bishop's Ubuntu 12.04 Ultimate Server Guide.

I actually created a series of ansible scripts to automate this process on my github.

So I have ldap+kerberos set up on a machine that client boxes are connecting to. I have a nas that is running an nfs server that serves up the /home directory to users in the domain. You can see my complete configuration on github minus my environment specific variables like passwords, etc.

Everything seems to be working except one problem. If I log into a machine as a domainadmin user I can use sudo to run commands like updating apt cache, but I cannot modify data in /home.

See the below, note that both users, ansible and jgrowl, are domainadmins:

ansible@ip-192-168-0-13:~$ pwd
ansible@ip-192-168-0-13:~$ ls -l /home
total 12
drwxr-xr-x 8 ansible    ansible    4096 Aug 12 14:07 ansible
drwxr-xr-x 7 jgrowl jgrowl 4096 Aug 12 14:08 jgrowl
ansible@ip-192-168-0-13:~$ mkdir test1
ansible@ip-192-168-0-13:~$ ls -l
total 4
drwxrwxr-x 2 ansible ansible 4096 Aug 12 14:06 test1
ansible@ip-192-168-0-13:~$ sudo mkdir test2
mkdir: cannot create directory `test2': Permission denied
ansible@ip-192-168-0-13:~$ sudo -u ansible mkdir test3
ansible@ip-192-168-0-13:~$ ls -l
total 8
drwxrwxr-x 2 ansible ansible 4096 Aug 12 14:06 test1
drwxr-xr-x 2 ansible ansible 4096 Aug 12 14:07 test3
ansible@ip-192-168-0-13:~$ sudo mkdir ~jgrowl/test4
mkdir: cannot create directory `/home/jgrowl/test4': Permission denied
ansible@ip-192-168-0-13:~$ sudo -u jgrowl mkdir ~jgrowl/test5
ansible@ip-192-168-0-13:~$ ls -l /home/jgrowl
total 16
drwxr-xr-x 2 jgrowl jgrowl 4096 Aug 12 14:08 test5

So sudo can only be used when specifying the user that directory belongs to. Does this make sense?

Here are a couple of files that are important:




Contents of /etc/exports on the nfs server

/export *(rw,fsid=0,crossmnt,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)
/export/home *(rw,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)

I know there is a lot going on here and is probably difficult to help me, but any suggestions would be appreciated!

share|improve this question
up vote 2 down vote accepted

It looks like your NFS shares are being exported with root_squash enabled, so the root user actually gets the permissions of nobody when trying to operate on NFS mounts. Look for a root or root squash option in your NAS exports and tweak that.

share|improve this answer
Hmm.. I'll look into this, I posted the contents of my /etc/exports above. – jgrowl Aug 12 '13 at 18:35
Yep. I don't see a "no_root_squash" in your /etx/exports options, and most NFS servers in my experience squash root by default. – John Aug 12 '13 at 18:52
Feels like this might be the problem, but adding the no_root_squash doesn't seem to fix anything :\ – jgrowl Aug 12 '13 at 19:07
You have to restart your NFS server (the process, not necessarily the machine) and remount the shares on the client(s). – John Aug 12 '13 at 19:38
I'm marking this as the answer as it seems right. I couldn't ever get it working with my setup though. Not sure if I needed to configure something else with kerberos or what. – jgrowl Aug 20 '13 at 14:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.