Problem with mounting of NFS share

I am struggling with the behaviour of a second NFS share from a NAS I am trying to set up on my workstation without success.
I have two NAS boxes both QNap one slightly older and running different firmware. However as far as I can see I have set up the shares on each in the same way with ssh required and the same parameters on both. I have been able to create NFS shares on my system using Yast. Here is my fstab:-

alastair@ibmserver2:~> cat /etc/fstab
UUID=46f191b6-7472-49c0-bd98-75824020d947       swap    swap    defaults 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /       btrfs   defaults 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /boot/grub2/i386-pc     btrfs   subvol=boot/grub2/i386-pc 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /boot/grub2/x86_64-efi  btrfs   subvol=boot/grub2/x86_64-efi 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /opt    btrfs   subvol=opt 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /srv    btrfs   subvol=srv 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /tmp    btrfs   subvol=tmp 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /usr/local      btrfs   subvol=usr/local 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/crash      btrfs   subvol=var/crash 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/lib/mailman        btrfs   subvol=var/lib/mailman 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/lib/named  btrfs   subvol=var/lib/named 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/lib/pgsql  btrfs   subvol=var/lib/pgsql 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/log        btrfs   subvol=var/log 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/opt        btrfs   subvol=var/opt 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/spool      btrfs   subvol=var/spool 0 0 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /var/tmp        btrfs   subvol=var/tmp 0 0 
UUID=B738-D576  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=4ceac2e7-6bdc-40d2-9dff-da7a2099bf45       /home   xfs     defaults 1 2 
UUID=a5a2612d-d0cb-4b05-a3cf-cc95ecd0235b       /.snapshots     btrfs   subvol=.snapshots 0 0 
UUID=4272b75a-ea72-4068-8826-e2dfc5611fd5       /data   xfs     defaults 1 2 
UUID=3ff724cf-7265-4bff-a3f6-343af8dcb7d2       /mnt/external   ext4    acl,user_xattr,nofail 1 2 
192.168.xxx.xx0:/Multimedia     /home/alastair/Nas_Multimedia_NFS       nfs     defaults 0 0 
192.168.xxx.xx1:/ibmserver2     /home/alastair/NAS_Backup_NFS   nfs     defaults 0 0 
alastair@ibmserver2:~> ^C


Both local files have the same ownership and permissions except for a + (what is that?). Here is an excerpt from running ls -l on my home directory:-

drwxr-xr-x   2 alastair users     6 Mar 30  2017 Music
drwxrwxrwx   3 root       101    40 Dec 23 13:01 NAS_Backup_NFS
drwxrwxrwx+ 10 root       101  4096 Mar 18  2017 Nas_Multimedia_NFS
drwxr-xr-x   5 alastair users    39 Feb 19  2016 perl5
drwxr-xr-x  14 alastair users  4096 Nov 15 20:04 Pictures


I interpret this to mean that both are seen correctly by my system and mounted on my home directory but there the similarities end.
The original share works as required. If I open its folder in my home directory (Multimedia) I can read but not write.
The second directory, intended for backups, I can create and open a directory on it but that does not appear on the NAS.
What other info should I look at to diagnose this problem?

I have no answer, but I will try to find one.

In the mean time a few remarks:

Are you sure these work: 192.168.xxx.xx0 and 192.168.xxx.xx1

In the home directory of alastair, there should be only files (and directories) that are owned by user alastair and certainly not owned by user root.
Files should never be owned by an undefined group.

And when you serach on the internet you will find that the + after the permissions means that some extended security information (like ACL) is used. And that may explain why you have no access.

It is always amusing to see people hiding private IP addresses …

What other info should I look at to diagnose this problem?

Personally I’d run tcpdump or tshark to capture on the wire traffic. That would answer where to look further. Make result available, so it can be looked at. Yes, it will expose your private IP addresses :slight_smile:

Where did OP say that? Read question carefully.

I admit I was not at my best here. I probably was distracted by the xx in the IP address (still wondering), and the vague description of what “works” or not (I interpreted that as access problems). :shame:

I still think we have to gather some basic information.

ls -l

of both directories when the NFS file systems are NOT mounted.

The same when they are mounted. And please prove that they are mounted with

mount | grep nfs

And then, please check how things are configured and owned on the server. Remind that user and group management on NFS servers and clients have to by synced to avoid ownership/permission (and thus security) problems.

Hi Henk and many thanks for the reply. My first reply has gone awol so am writing again.

Some progress. In spite of my fstab showing both shares one is clearly not mounted:-

alastair@ibmserver2:~> mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.169.130:/Multimedia on /home/alastair/Nas_Multimedia_NFS type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.169.130,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=192.168.169.130)
alastair@ibmserver2:~>

With both directories not mounted I get:-

alastair@ibmserver2:~> ls -l
total 264
drwxr-xr-x  2 alastair users     6 Dec  4  2015 bin
drwxr-xr-x  2 alastair users   146 Dec  4  2015 Desktop
drwxr-xr-x 12 alastair users   307 Jun 25 10:03 dfsee_13
drwxr-xr-x  3 alastair users    42 Jul 21 18:21 dfsee_14x
drwxr-xr-x  2 root     root     25 Jul 21 18:25 dfsee_work
-rw-r--r--  1 root     root  89939 Jul 22 11:46 dfsifstd.log
-rw-r--r--  1 root     root   2946 Jul 21 21:50 dfspuppy.log
-rw-r--r--  1 root     root  29562 Jul 21 21:50 dfswork.log
drwxr-xr-x 31 alastair users  8192 Dec 23 11:33 Documents
drwxr-xr-x 51 alastair users 12288 Dec 23 12:17 Downloads
drwxr-xr-x  3 alastair users    81 Jan 28  2017 ffmpeg
drwxr-xr-x  2 alastair users  4096 Aug  8 14:37 flv_videos
drwxr-xr-x  2 alastair users 28672 Dec 23 02:25 GiP_Recordings
drwxr-xr-x  3 alastair users    29 Sep 21 20:39 Handbrake_Rips
-rw-r-----  1 alastair users 16139 Apr  7  2017 hp-check.log
-rw-r--r--  1 alastair users 20031 Nov 22 18:04 Iris_Hildegard_1.m3u
-rw-r--r--  1 alastair users 21705 Nov 22 18:04 Iris_Hildegard_1.m3u~
lrwxrwxrwx  1 alastair users    16 Feb 22  2016 mastermedia -> /data/multimedia
drwxr-xr-x  6 alastair users    81 Apr  5  2016 movie
drwxr-xr-x  2 alastair users     6 Mar 30  2017 Music
drwxr-xr-x  2 alastair users     6 Dec 23 15:28 NAS_Backup_NFS
drwxr-xr-x  2 alastair users     6 Jul 20  2016 Nas_Multimedia_NFS
drwxr-xr-x  5 alastair users    39 Feb 19  2016 perl5
drwxr-xr-x 14 alastair users  4096 Nov 15 20:04 Pictures
drwxr-xr-x  2 alastair users     6 Mar  8  2016 Public_NFS_Share
drwxr-xr-x  3 alastair users    30 Dec 15 12:13 rips
drwxr-xr-x  3 alastair users  4096 Nov 10 11:39 scanned_docs
drwxr-xr-x  2 alastair users     6 May 28  2016 SD_Card_Work
drwxr-xr-x  8 alastair users  4096 Dec 23 11:30 SongKong
drwxr-xr-x  3 alastair users    48 Mar 18  2016 Tagging_Testing
drwxr-xr-x  3 alastair users  4096 Jan 26  2017 temp
drwxr-xr-x  2 alastair users   322 Apr 17  2017 tmp
drwxr-xr-x  2 alastair users     6 Oct 16  2016 Videos
drwxr-xr-x  4 alastair users    38 Jan 24  2016 VirtualBox VMs
drwxr-xr-x  4 alastair users   112 Nov 22 17:54 Working
alastair@ibmserver2:~> 


Which looks correct for both directories intended for NFS mounts.

Now in Yast both NFS shares are shown and are the same except for the IP address of server which brings me to the logical question. How are these shares mounted and why did one mount and the other not?
PS,
Went back to edit typo in this message and then found the Multimedia NFS has mounted again without any action from me!!! Sadly the other is still not mounted. When I look at it in Dolphin I get the following error message:-

An error occurred while accessing ‘/ibmserver2 on 192.168.169.131’, the system responded: mount.nfs: access denied by server while mounting 192.168.169.131:/ibmserver2

Which answers your question why this filesystem is not mounted. Your server is not configured to allow your client to mount this directory (assuming your server exports this directory at all).

The error message quoted in my last reply suggested something not right on the NAS. It is likely I should revise all users on both NAS boxes but meanwhile on the working NFS I have used “admin” and the NAS admin password.

I ran into all kinds of complications with the KDE Wallet system on my workstation so have disabled it.

Now as I have set up the NAS only to allow access using SSH I would have expected a password request for both NFS shares before they mount. As it happens and even after logging out and back in to my system, the original share still works without me giving the ssh password but the second share gives me an error message in Dolphin when I click on the remote directory:-

 An error occurred while accessing '/ibmserver2 on 192.168.169.131', the system responded: mount: only root can mount 192.168.169.131:/ibmserver2 on /home/alastair/NAS_Backup_NFS


I hope this further info helps.

No, that’s not how NFS works. It does not perform any per-user authentication. Either your host is allowed to mount or not.

I hope this further info helps.

Not really. You need to look at your server setup, what it exports and with which options.

Well, that confirms what you reported, that you can store data in the NAS_Backup_NFS directory, but that it does not show in the server. That is because there is no mount active and thus it is stored locally (do not forget to clean up there, it will take storage space).
I do not know why you call this;progress: however.

It seems that you think that /etc/fstab show what is mounted. It does not. It does contain a configuration of file systems that can be and often should be mounted.

So the next step is obviously to test why this mount, that should have been done on boot, failed. Simply by mounting it and then look at the messages.
Now, you did that already without understanding why (see later) and there is an error message:

An error occurred while accessing '/ibmserver2 on 192.168.169.131', the  system responded: mount.nfs: access denied by server while mounting  192.168.169.131:/ibmserver2
 

This says it is the server!

Yes, that looks correct. Remark the owner user and group are correct here.

Off topic: those files owned by root should not be there. It probably points to you running things as root in an unproper (and thus potential dangerous) way.

I am not sure why Dolphin is used here. Do you, by all means, run Dolphin as root?

==========

I also asked for a ls -ld of those two directories when mounted. You can not do that for the second, but you can for the first. If that results in what we saw in your first post: owned by root and 101 then your NFS server is not used properly.

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

I see those xxxx have gone. @avidjaar siggests that this was a sort of hiding. I have two remarks about that:

  1. People here trust that what one posts between CODE tags is the complete, unchanged and unabridged text as it was on the terminal. When one needs to change something (e.g.to hide a readable password) this must be communicated.
  2. almost all DHCP servers in almost all routers serve IP addresses in that private address range, thus there is nothing to hide.

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

PS, I had some hardware trouble here, thus my post comes a bit late, but I hope you still can learn something from it.

And I do not understand what ssh has to do with it. You probably use ssh to connect to the servers for management work. But that has no influence on the way NFS works.

OK, but I am learning (slowly).

I never use root unless I must. Only occasionally I use Dolphin in super user mode such as just now to unmount the working share.

The directory that marks the NFS mount which is working now shows it is owned by root again.

drwxr-xr-x   2 alastair users     6 Dec 23 15:28 NAS_Backup_NFS
drwxrwxrwx+ 10 root       101  4096 Mar 18  2017 Nas_Multimedia_NFS


I assume this is correct for the way the share is working at present, even if not being used properly.

All the posts here now point to a problem on the server end so I must look harder there. As I indicated earlier the two are set up the same as far as I can tell.
I shall now try and set up another share on the NAS that works and see if I can eliminate some other issues.
Many thanks for all your help and if you are stopping work for the holiday I wish you a Merry Christmas.
Regards,
Budgie2

I would never do that with a GUI file manager (gives me the shivers), but always use

su -c 'umount .......'

It of course shows correct that on the server the wrong user/group is owner.

I agree but have been using web control pages for the NAS and as I recall the Multimedia directory was already installed. In fact if I go to the shared folder page and check permissions using properties only “admin” who is root as far as NAS is concerned, has read and write permission but if I use their “File Station” page and right click on the same folder and select properties all the users of the subdirectories and their permissions are shown and most have read and write permissions. Rather confusing for simple chap like me.

Moving on to my test, I set up another shared directory on the NAS which has the working NFS share as a test directory, again using the web control pages and logged in as admin. (In the first machine that used to be the only log in possible) I then set up the NFS using Yast.

I now have:-

alastair@ibmserver2:~> mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.169.130:/Multimedia on /home/alastair/Nas_Multimedia_NFS type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.169.130,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=192.168.169.130)
192.168.169.131:/ibmserver2 on /home/alastair/NAS_Backup_NFS type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.169.131,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=192.168.169.131)
192.168.169.130:/Test_NFS_Folder on /home/alastair/NAS_Test_NFS_Folder type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.169.130,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=192.168.169.130)
alastair@ibmserver2:~> 


and

drwxr-xr-x   2 alastair users     6 Mar 30  2017 Music
drwxrwxrwx+  5 root     root   4096 Dec 23 17:37 NAS_Backup_NFS
drwxrwxrwx+ 10 root       101  4096 Mar 18  2017 Nas_Multimedia_NFS
drwxrwxrwx+  3 root     root   4096 Dec 23 17:34 NAS_Test_NFS_Folder
drwxr-xr-x   5 alastair users    39 Feb 19  2016 perl5


In other words, on finishing setting up the third NFS share in Yast, all three NFS shares started working without me changing anything on the second NAS box!!!
I feel I have made some progress but cannot say I understand what happened.

What I want to do now is return to Luckybackup and KDE Wallet problems and then try and create all that I have now in my own name and group.
Many thanks once more.