Tag: NFSv4

Lubuntu 19.04 : NFSv4 server seems to allow only ver=3

I just upraded an old ASUS atom desktop to be a file server and installed Lubuntu 19.04 serving 3 sub folders to my LAN with various machines running raspbian, ubuntu and mate.

I got the NFS server up and running in similar was on all machines for several years, but was surprised to see my clients mounting lubuntu server with NFS ver=3 like this:-

andrew@VESA-ubuntu:/nfs$   nfsstat -m            /nfs/all/Elements1Tb from 192.168.1.106:/media/ab/Elements1Tb  Flags: rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.106,mountvers=3,mountport=57921,mountproto=udp,local_lock=none,addr=192.168.1.106

All other servers mount NFSv4 as planned.

The autofs is setup on simple basis like this (/etc/auto.nfs):

Medion1Tb  -fstype=nfs4,rw 192.168.1.106:/media/ab/Medion1Tb

Is see both clients and server have recent versions of NFS (1.3.4-2)

What am I missing to get NFSv4 working on the lubuntu server?

Inability to set filesystem permissions after mounting NFSv4 with KRB5 or AUTH_SYS

I have a Kerberized NFS share that I am able to mount and access using a macOS client. Regardless of whether I specify Kerberos authentication on the server side or AUTH_SYS, I am unable to write to the share.

Specifically, the permissions on the files/folders on that share are read-only (the ownership is root:wheel).

enter image description here

I am unable to change the owner or the permissions using Finder or CLI. For example, the command:

chown -R <local-or-LDAP-user> <folder>

returns

Operation not permitted

I’ve played around with root_squash, etc. The local machine account differs from the LDAP/Kerberos principal entry (used by the NFS server). I’ve alleviated the mismatch by adding a user by the same name into LDAP, and even matching UIDs between the local account and the LDAP entry.

None of this seems to have any effect.

How to configure NFSv4 mount so that owner of files created by root user on NFS client appear as ‘root:root’, rather than ‘nobody:nogroup’ on client?

I have an Ubuntu 16.04 server on which the Nextcloud snap is installed (nextcloud.lan), and an Ubuntu 16.04 NAS configured to serve files over NFSv4 (nas.lan). I would like to mount directory /var/snap/nextcloud on nextcloud.lan via an NFS directory exported from NAS, so that all of files used by Nextcloud are stored on the NAS.

NFS authentication on the NAS is configured as default AUTH_SYS/AUTH_UNIX. Please see the following configuration files for nas.lan:

/etc/idmap.conf:

[General]  Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname Domain = localdomain

/etc/exports:

/vol0/export 192.168.2.0/24(rw,fsid=0,insecure,no_subtree_check,async) /vol0/export/nextcloud 192.168.2.0/24(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

And for nextcloud.lan:

/etc/fstab:

nas:/nextcloud /mnt nfs auto 0 0

/etc/idmap.conf:

[General]  Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname Domain = localdomain

Currently, when a user with a uid that exists on both nas.lan and nextcloud.lan creates a file (e.g username jacob, uid 1000) in the mounted dir on nextcloud.lan, the file is created with the appropriate owner on both systems (e.g. jacob:jacob).

However, when the root user creates files in the exported directory on nextcloud.lan, the files appear to be owned by “nobody:nogroup” in both systems. The Nextcloud snap is only able to run as the root user, and so my question is, how can I make it so that files created by root user on NFS client nextcloud.lan appear as ‘root:root’, rather than ‘nobody:nogroup’?

I have read that NFS does some special handling around root user permissions, and does not map root user id between systems for security reasons. I am wondering if there is a way to override this?

I saw that there is one option called no_root_squash, but this has not worked for me.

I also tried setting the following in /etc/idmapd.conf on nextcloud.local, but this has also not worked for me:

[Mapping] Nobody-User=root Nobody-Group=root

So far, I have tried everything I can think of to map nobody:nogroup to root:root on the nextcloud.lan system, without success.

I would appreciate any insight anyone can share on how to do this. Thank you for your help.

Diagnosing NFSv4 Authentication Issues

I’ve got a couple of NFSv4 shares (with Kerberos authentication). Most of the time they work quite well, but when there’s an issue they can be a pain to fix.

I put this down to them being quite opaque as far as internal operations and error messages go – I can tell it isn’t working but can’t easily see the details of what’s going on. I generally just resort to checking the bread and butter issues (clock sync, keytabs correctly installed, etc) and muddling through.

So I thought I’d throw this question out there: When NFS/Kerberos authentication is failing, what is a good way to get more visibility on what’s going on and understanding the root cause of the problem.

list directory is slow when using NFSv4

I’m currently setting up NFS based file sharing between my Mac client (Macos 10.14.1) and Raspberry Pi3 server (U16.04.1 LTS). As I dual-boot my Mac (MacOS/Ubuntu18) I want to use my Pi with NFS (I already have Samba running well, but it doesn’t handle Unix permissions) as a common home to reduce duplication of files and simplify version control. After I get MacOS working properly, I will tackle the Ubuntu setup.

I have two shares setup at the moment, one using NFS3 (anonymous), the other using NFSv4 (home/user1). Reading/writing files to either of the shares is very fast and working well (other than UID/GID mismatches). Where I have a problem is that whilst listing the files on the NFS3 share is also very fast, listing files on the NFSv4 share is VERY slow and I can’t figure out why.

Below are all the settings I’m using. I haven’t used mount --bind on the server as I don’t think its necessary and doesn’t have anything to do with my problem, but I may be wrong.

I’ve been searching for solutions to this problem for a number of days however nothing I’ve read addresses my problem, whereby others always complain about directories with large numbers of files, nor have any of the suggestions I’ve seen fixed my problem.

Ultimately, I want to synchronise UIDs/GIDs between my Mac and Pi, but that is another question as I don’t now much about setting up LDAP (or using NIS?) with (but hopefully without) Kerberos. In addition, I don’t have a domain controller setup right now.

Thanks in advance for taking the time to read about my problem and your suggestions.

Server Side
/etc/exports: 

/srv/anonymous *(rw,sync,insecure,no_subtree_check,all_squash) /srv/home/user1 *(rw,sync,fsid=0,insecure,crossmnt,no_subtree_check,no_root_squash)

/etc/default/nfs-common: 

NEED_STATD= NEED_IDMAPD=yes STATDOPTS="--port 4000 --outgoing-port 4001" NEED_GSSD=

/etc/default/nfs-kernel-server: 

RPCNFSDCOUNT=8 RPCNFSDPRIORITY=0 RPCMOUNTDOPTS="--manage-gids -p 4002" NEED_SVCGSSD="" RPCSVCGSSDOPTS="" RPCNFSDOPTS=""

/etc/idmapd.conf: 

[General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs  [Translation]    Method=static [Static]    user1@mac.local = user1  [Mapping] Nobody-User = nobody Nobody-Group = nogroup

/etc/modprobe.d/blacklist.conf: 

blacklist rpcsec_gss_krb5

/etc/modprobe.d/options.conf: 

options lockd nlm_udpport=4001 nlm_tcpport=4001

/etc/modules:

lockd

/sys/module/nfsd/parameters/nfs4_disable_idmapping: 

Y  (I've tried manually setting this to "N" but it gets overwritten)    (So I'm using nfs-common to manage this via the 'NEED_IDMAPD=yes' option

Client Side
Mounting performed using:

mount -v -t nfs -o proto=tcp,port=2049 raspberry.local:/srv/anonymous ~/ranonymous mount -v -t nfs -o rsize=32768,wsize=32768,proto=tcp,port=2049,sec=sys raspberry.local:/srv/home/user1 ~/ruser1

Results of time ls /share: 

user1@mac:[ 6:13]$   time ls ranonymous/ a1        putty.zip test  real    0m0.013s user    0m0.002s sys     0m0.004s user1@mac:[ 6:13]$   time ls ruser1/ a1        a2        a3        a4        a5        me        me copy   myScripts you       you1      you2      you3  real    0m6.044s user    0m0.002s sys     0m0.004s