0

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.

  • no_root_squash is dangerous. If you don't know exactly what you're doing, you'll open up your network to allowing users to leverage root on one machine and get it on another. And the fact that you had to ask this question means you don't really understand it. You'd do much better modifying whatever processing you're doing to not run as root. Nothing should run as root outside OS-necessary processes. – Andrew Henle Jan 7 at 22:27
  • @AndrewHenle Thank you for your insight on this. I agree, nothing should run as root. Unfortunately, a known shortcoming of the nextcloud snap is that it can only run as root: github.com/nextcloud/nextcloud-snap/issues/457 – jbeard4 Jan 8 at 3:41
  • Is there a way to map the root user on nextcloud.lan to a non-root user on nas.lan? – jbeard4 Jan 8 at 3:50
  • @jbeard4 you can enforce uid/gid for user nobody (which is root if no_root_squash option is not specified) by explicitly specifying anonuid= and anongid= – kofemann Jan 8 at 9:27
1

You have two entries in the export file that overlap:

/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)

any client within subnet 192.168.2.0/24 may (and probably does) uses the first entry and ends up mapping root to user nobody. Try to narrow down the IP range:

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

where 192.168.2.1 is supposed to the IP address of nextcloud.lan.

  • Clients don't use export entries like that. Having exports as subordinate directories to another export does not cause any selection from the client to be made for one export or another. They can be mounted independently of one another, and the export directory is part of the client login request (rather than some kind of server or client side guesswork). The field you're talking about is for restricting access to an export based on IP, not a method of assigning exports to hosts (though in your example, it behaves somewhat similarly to the concept of assignment). – Spooler Jan 8 at 4:47
  • This is true for NFSv3, where an extra request sent to mound service to discover file handle based on path. However, with NFSv4 there is no concept of export path. A pseudo-fs is created which represents the virtual export tree. – kofemann Jan 8 at 9:16
0

I was able to achieve this with the following modification to /etc/exports:

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

I was then able to mount /var/snap/nextcloud via NFS to the exported directory on the nas, and everything seems to work well.

However, I agree with @AndrewHenle -- this approach seems dangerous and insecure, and it would be better to find an approach that mapped the root user on nextcloud.lan system to a non-root user on the nas.lan system. Unfortunately, the nextcloud snap needs to run as root at this time. I may spawn this off into a separate question.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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