# permission issue using nfsv4 [solved]

## javeree

background: 

I wanted to run a dovecot server on nfsclient, and export the mail spool as '/mnt/mail' via nfsv4.

user 'jan' has uid 1002 on nfsclient and uid 1000 on nfsserver, so my first attempt resulted in /mnt/mail/jan/* to be owned by another user who happened to have uid 1000 on the nfs server.

=> I ran idmapd on both nfsclient and nfsserver, restarted the server and remounted the share.

As user jan, I get for "ls -ld /mnt/mail/jan /mnt/mail/jan/*"

 *Quote:*   

> ls: cannot access '/mnt/mail/jan/*': Permission denied
> 
> drwx------ 300 jan root 20480 Mar  6 18:12  /mnt/mail/jan

 

Stilll, I see that files /mnt/mail/jan/* are owned by user jan:

Now running as root on nfsclient: ls -ld /mnt/mail/jan /mnt/mail/jan/*

 *Quote:*   

> drwx------ 300 jan root   20480 Mar  6 18:12 /mnt/mail/jan
> 
> drwx------   2 jan root  290816 Mar  6 18:11 /mnt/mail/jan/cur
> 
> -rw-------   1 jan users  21160 Mar  6 18:09 /mnt/mail/jan/dovecot.index
> ...

 

I got some extra information from dovecot running on nfsclient. I can start dovecot alright, but when I try to read my inbox, I get the following in dovecot log:

 *Quote:*   

> Mar 06 18:26:11 [dovecot] imap-login: Login: user=<jan>, method=PLAIN, rip=192.168.1.20, lip=192.168.4.58, mpid=24281, TLS, session=<L3wE8zKgwJDAqAEU>
> 
> Mar 06 18:26:11 [dovecot] imap(jan)<24281><L3wE8zKgwJDAqAEU>: Error: stat(/mnt/mail/jan/subscriptions) failed: Permission denied
> 
> Mar 06 18:26:11 [dovecot] imap(jan)<24281><L3wE8zKgwJDAqAEU>: Error: open(/mnt/mail/jan/dovecot.list.index.log) failed: Permission denied (euid=1000(jan) egid=1000(jan) missing +x perm: /mnt/mail/jan, UNIX perms appear ok (ACL/MAC wrong?))
> ...

 

The key here seems to be that somehow /mnt/mail/jan/ is owned by root:users instead of jan:root as the ls command thinks.

But here I am stuck. What could cause this 'incorrect' ownershipLast edited by javeree on Thu Mar 19, 2020 9:24 am; edited 1 time in total

----------

## alamahant

Hi,

Maybe you can use use kerberzed nfs4(dovecot is kerberos-aware).

Plz have a look here:

https://wiki.dovecot.org/Authentication/Kerberos

----------

## javeree

Tonight I'll have a look at setting up and using kerberos. It'll be a first for me, but somethign I've been putting off for too long. My main reason so far to avoid a centralized user management is the bunch of Windows home systems that can't play together with an AD. But in this case, it is nfs, which I only use between my linux systems.

----------

## Ant P.

 *Quote:*   

> UNIX perms appear ok (ACL/MAC wrong?)

 

This part of the error looks more significant to me. Do you have plain unix perms on both machines or are things like ACLs/SELinux active?

----------

## javeree

Yes, that seems more relevant. I checked the Kerberos page, but that is about authenticating to dovecot. That authentication works fine. I used dovecot just because it gave me a more verbose message, but the problem also appears with standard utilities such as ls, where I get  a 'Permission denied' trying to access the folder.

I definitely do not have SELinux active, and as far as I know don't have ACL either. Below are the mount on the server and on the client side, but maybe this is not the best way to check for acl ? 

Server side: mount | grep mail

 *Quote:*   

> 
> 
> /dev/sdb5 on /mnt/mail type ext4 (rw,noexec,noatime)
> 
> /dev/sdb5 on /export/mnt/mail type ext4 (rw,noexec,noatime)
> ...

 

Client side

 *Quote:*   

> Hermes:/mnt/mail on /mnt/mail type nfs4 (rw,noexec,noatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.20,local_lock=none,addr=192.168.1.43,_netdev)

 

However, I do see in my kernel config: zgrep ACL /proc/config.gz

 *Quote:*   

> CONFIG_EXT4_FS_POSIX_ACL=y
> 
> CONFIG_FS_POSIX_ACL=y
> 
> CONFIG_TMPFS_POSIX_ACL=y
> ...

 

and lsmod | grep -i acl

 *Quote:*   

> 
> 
> nfs_acl                16384  1 nfsd
> 
> sunrpc                241664  18 auth_rpcgss,nfsd,nfs_acl,lockd
> ...

 

So it is possible that I do have it active. If so, what should I check next ?

----------

## alamahant

Then either adjust uid and guid of users to be the same across both server and client or maybe use a centralized user repository like perhaps ldap?

OR it would be best if user@domain of nfs4 really works as it should.

Apparently you have to enable it @boot time (if not already enabled).

Maybe you should create a file in /etc/modprobe.d to activate it: 

```

options nfs nfs4_disable_idmapping=0

options nfsd nfs4_disable_idmapping=0

```

and in /etc/idmapd.conf set your domain BOTH in server and client

Maybe also enable and start

nfs-idmapd

 :Very Happy: 

----------

## javeree

This got kinda solved, but more because the basic configuration changed than because of finding the root cause with the existing configuration.

First of all, I thought I was using nfsv4, as I was mounting with -t nfs, and assuming it would use the highest protocol version. It turned out to fall back to v3.

Here, the key was that I had in /etc/exports:

 *Quote:*   

> /export 192.168.0.0/255.255.127.0(insecure,rw,sync,no_subtree_check,crossmnt,fsid=0)
> 
> /export/mnt/mail 192.168.0.0/255.255.127.0(insecure,nohide,rw,subtree_check,no_root_squash)
> 
> 

 

It only worked when I changed the permissions for /export:

 *Quote:*   

> /export *(insecure,rw,sync,no_subtree_check,crossmnt,fsid=0)
> 
> /export/mnt/mail 192.168.0.0/255.255.127.0(insecure,nohide,rw,subtree_check,no_root_squash)
> 
> 

 

The second error, which is related to the userid issue:

/etc/idmapd.conf in both client and server need the line

 *Quote:*   

> Domain = mydomain

 

which is by default commented out.

uncommenting resulted in the correct user mapping.

----------

