NFS Server and Client, optimal locations of share folders and giving write access to clients

English Network/Internet
#1

I am able to set up a NFS server and client. I am not able to grant write access to the clients.

I would like to know where are the optimal locations for the share folder on the NFS server and the mount folder on the NFS clients and how to give the client folder write access.

Using yast, I created the server and shared the folder at /home/user1/shareNFS. Through dolphin, the share folder was set to rwx for user, group and owner. I created the client and mounted the share folder at /home/shareNFS.

This was a poor choice. It crashed all user access on the client. Fortunately I was able to log in through root, remove the NFS client and restore user access.

I recreated the NFS client and mounted the share folder at /home/user1/shareNFS. This creates a read-only folder accessible to all users on the client.

There must be a better approach for share folder placement. One thought is to create a unique user, such as “share” on the server and client and use /home/share/shareNFS as the share folders. This does not resolve the write privilege issue.

Thank you in advance for your help.

#2

I do not understand all what you wrote above (mainly because it is only story telling without any computer text of configuration files, listing of the files users can not access with owner/permissions, etc.).

But the main things to take care of are basically the same things as if the directories/files where not on a NFS-mounted files system, but on the client system itself. User/group ownership and permissions of directories/files (and the directories in the path leading to them) decide who may do what with them.

Thus it is important to understand that it is wise to have the same users/groups on the server and on the client (at least as far as they are involved). Take care that this is about the UIDs and GIDs, the numbers, though it is of course more easy for human beings to attach the same user names and group names to those UIDs and GIDs.

Where to put stuff on the NFS server.
As often this depends much on how they are used on the server itself. When the server is also used by the user to log in, the exported directory will probably be somewhere in his/her home directory and then will be mounted in the same place on the client, to make the user find his files in the same place on both systems. When the server is just a storage device it does not matter much, organising the server in a logical way then.

On the client there are basically two schools.
One way is to mount the user’s data somewhere in his/her home directory on a place that he/she would like to have it.
The other is to mount it somewhere in /mnt (or another directory in / specially created for this) and the user can then make a symbolic link from the place in the user’s home directory to that mount point.
In both cases, do not forget that the mount point must be owned by the user/group.

In all cases, the user can then decide (by manipulating permissions) who may access (rwx) his/her files like he/she does so for all his/her other (not NFS-mounted) files.

=====================

And please, when experimenting further and asking here for help with it, then show your present situation by posting information like:

on the server

cat /etc/exports

ls -l <of-an-exported-directory>

On the client

grep nfs /etc/fstab

mount | grep nfs

ls -l <of-the-mount-point>

Then we have something to start from.

#3

Thank you for your reply

created the folder /shareNFS
created a new user nfs
changed the user of /shareNFS to nfs
created the nfs server mounting to /shareNFS
created the nfs client mounting to /shareNFS

cat /etc/exports
/shareNFS *(ro,root_squash,sync,no_subtree_check)

cd /
ls -l
drwxr-xr-x 1 root nfs 0 May 22 11:46 shareNFS
(I did not include the other folders such as binn, boot, etc.)

chmod u+w shareNFS
chmod: changing permissions of ‘shareNFS’: Read-only file system

grep nsf /etc/fstab
(no output)

mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
MainHost:/shareNFS on /shareNFS type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retra
ns=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.2)

ch /shareNFS
ls -l
total 0

I just noticed that I did not open the firewall during the client set up. I will retry all my steps and set the user privileges prior to created the nfs server and client.

#4

Please, please use CODE tags around your computer text. One of the things it brings is a clear boundary between story telling and computer facts. This is missing here where all (well most) is in a fixed font, story or not.

Maybe you mis this information:

There is an important, but not easy to find feature on the forums.

Please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt.

==================

And please, make it very, very clear what is on the server and what on the client. Whjen you just say

created a new user nfs

it is not clear on which system.

Also creating the user is not enough. As I said earlier the user name is NOT important (but having the same on both system will help everybody’s understanding), the UID is important… Does on bothe systems we need

grep nfs /etc/passwd

to check that.

#5

Thanks for all your help. After rereading your reply, I think my problem was that I had assigned the local and shared folders assigned to the same location.

I tried this on a different computer.

Through yast, I created a new group “nfs”. (This provides more granularity at giving users access to the share folder. That is, I can add a user without having to make them part of the group.)

In konsole (Not sure how to do code tags. I am using xml format <code> </code>. linux:/> is the command line prompt.)


linux:/>su
password:
linux:/>cd /
linux:/>mkdir shareNFS
linux:/>mkdir shareNFSlocal
linux:/>chown root:nfs shareNFS
linux:/>chown root:nft shareNFSlocal
linux:/>chmod g+w shareNFS
linux:/>chmod g+w shareNFSlocal
linux:/>ls -l
drwxrwxr-x   1 root nfs      0 May 22 13:51 **shareNFS**
drwxrwxr-x   1 root nfs      0 May 22 13:51 **shareNFSlocal
**

yast–>nfs server
set the mount point to /shareNFS

yast->nfs client
set the mount point to /shareNFS
set the local folder to /shareNFSlocal

logout/login




linux:/>grep nfs /etc/fstab
localhost:/shareNFS                        /shareNFSlocal           **nfs**    defaults                        0  0
linux:/>mount | grep nfs
sunrpc on /var/lib/**nfs**/rpc_pipefs type rpc_pipefs (rw,relatime)
**nfs**d on /proc/fs/**nfs**d type **nfs**d (rw,relatime)
localhost:/shareNFS on /shareNFSlocal type **nfs**4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr
=::1)

With dolphin, I am able to read and write files to /shareNFS. /shareNFSlocal is read only.

I do not understand the purpose of the /shareNFSlocal folder.

I think the problem is solved. I will try this on the real network as see what happens.

Thanks again for all your help. You have been very helpful to me in the past, as well.

#6

Re CODE tags:

It seems that you are not using the Web interface to the forums?
When you are not able to click the # button, then know that all tags in these forums are identified by …] not by <…>. I ttried to repair your post above to make it readable.

I still do not understand what you are doing.

You seem to create a directory shareNFSlocal and then later ask why it is there???

Also you mount from localhost, thus your server being the same system as your client. You never explained that you used this very unusual situation. Thus how can we know that???
And yes:

I think my problem was that I had assigned the local and shared folders assigned to the same location.

When you mount over a directory that has data, you can not see the original data anymore. Thus with using NFS locally you create very special situations :(.

For the rest I am still lost because of your untidy way of reporting. Agrevated by the fact that client and server are the same, thus I can not detect which is done where because the prompts are the same.

Also, can’t you keep Dolphin out of this? As soon as you can show that ownership and permissions are correct, you can test with simple commands like cat, touch and vim that you can read, write and change. Then GUI tools can of course do the same.

#7

It may help if, you can provide the following information:

  1. Did you setup NFSv3 or NFSv4?
  2. If NFSv4, how do you handle the user’s authentication?

Just a hint, the openSUSE documentation may prove to be helpful: <https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.nfs.html>.

  • For example, I’ve noticed, just now, that, in “/etc/exports” the ‘–bind’ mount is deprecated
    … :shame:
#8

I read and re-read it, but could not find it. The only thing I see is:

On openSUSE prior to Leap, the bind mount in /etc/exports was mandatory. It is still supported, but now deprecated.

Which is some feature, but not the whole of /etc/exports IMHO.

#9

Also took a 2nd look: it’s part of the “refer=path@host+host]:path@host+host]]” export option …

#10

I think I’ve got it working. Still something does not make sense.

Users in the group “nfs” are able to read and write to the remote directory, located at: /shareNFS.
However, root and these users are not able to write to the client mount point, located at /shareNFSlocal, even though write privileges are enabled.

Here is how I set up the client using yast:

NFS Client Configuration

NFS Shares
server: MainHost
Remote Directory /shareNFS
Mount Point /shareNFSlocal
NFS Typ nfs
Options minorversion=1

NFS Settings
Enable NFSv4

Here is some code performed in super user mode.


**linux-eqqf:/ #** ls -l
total 0
drwxr-xr-x   1 root root  1760 May  5 15:05 **bin**
drwxr-xr-x   1 root root   998 May 24 15:56 **boot**
drwxr-xr-x  20 root root  3940 May 24 15:56 **dev**
drwxr-xr-x   1 root root  5204 May 24 16:58 **etc**
drwxr-xr-x   8 root root    87 May 21 10:11 **home**
drwxr-xr-x   1 root root  2546 May  9 10:43 **lib**
drwxr-xr-x   1 root root  5178 May  9 10:43 **lib64**
drwxr-xr-x   1 root root     0 May  9  2017 **mnt**
drwxr-xr-x   1 root root     0 May  9  2017 **opt**
dr-xr-xr-x 264 root root     0 May 24 15:55 **proc**
drwx------   1 root root   418 May 24 17:01 **root**
drwxr-xr-x  31 root root   940 May 24 16:58 **run**
drwxr-xr-x   1 root root  4654 May 14 11:03 **sbin**
drwxr-xr-x   1 root root     0 May  9  2017 **selinux**
drwxrwxr-x   1 root nfs      0 May 23 17:03 **shareNFS**
drwxrwxr-x   1 root nfs      0 May 23 17:00 **shareNFSlocal**
drwxr-x---   1 root root   172 May 24 15:52 **.snapshots**
drwxr-xr-x   1 root root    28 Feb 16 12:38 **srv**
dr-xr-xr-x  13 root root     0 May 24 15:57 **sys**
drwxrwxrwt   1 root root 52562 May 24 17:00 tmp
drwxr-xr-x   1 root root   130 Feb 16 12:29 **usr**
drwxr-xr-x   1 root root   112 Feb 16 12:55 **var**
**linux-eqqf:/ #** grep nfs /etc/fstab
MainHost:/shareNFS                         /shareNFSlocal           **nfs**    minorversion=1                  0  0
**linux-eqqf:/ #** mount | grep nfg
**linux-eqqf:/ #** cd shareNFSlocal
**linux-eqqf:/shareNFSlocal #** echo hello > temp.txt
bash: temp.txt: Read-only file system
**linux-eqqf:/shareNFSlocal #** cd ..
**linux-eqqf:/ #** cd shareNFS
**linux-eqqf:/shareNFS #** echo hello > temp.txt
**linux-eqqf:/shareNFS #** ls
temp.txt
**linux-eqqf:/shareNFS #**

To reiterate, I do not understand why root cannot write into /shareNFSlocal.

Thanks again to everyone for all your help.

#11

It seems that, you’re mounting a local directory (/shareNFSlocal) via NFS to another local directory (/shareNFS).

Please be aware that, usually, in “/etc/exports”, with respect to the area of “User ID Mapping”, the option ‘root_squash’ is enabled by default …

#12

It is a normal safety precaution that root of the client has the same permissions as other users (not owner or group permissions) on an NFS mounted file system. There is no guarantee that those who know the root password on the client also should have rights to root privileges on the server!

This security (root squashing) can be switched off (or the access as root switched on, how you like to formulate it). Just read

man exports