Bug 28907 - M8 NFS directory share does not seem to work for me
Summary: M8 NFS directory share does not seem to work for me
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-11 19:45 CEST by William Kenney
Modified: 2021-05-15 02:23 CEST (History)
3 users (show)

See Also:
Source RPM: nfs-utils
CVE:
Status comment:


Attachments

Description William Kenney 2021-05-11 19:45:45 CEST
Description of problem:

Sorry to have brought up this issue so late in the M8 cycle.
I just really got around to setting up my main server.

I have an M7.1 server that shares two drives across many platforms,
including M7.1, M8 and Raspberry Pi's. That all has been working fine for years.
Real hardware and Vbox clients.
This may be because something has changed that I didn't know.
My NFS share set up has been working just fine using the following:

Lets share: /home/wilcal/share  at LAN 192.168.0.21
let everyone get to it.
drwxrwxrwx 34 wilcal wilcal  4096 May 11 09:05  share/

MCC: Network Sharing -> Share drives and directories using NFS
install nfs-utils
MCC: Share drives and directories using NFS
     Add -> Directory: /home/wilcal/share
            Access: *
            User ID: No user UID mapping
            Anonymous user ID: (blank)
            Anonymous Group ID: (blank)
            Advanced: all no
            
Share Directory         General Options
/home/wilcal/share      no_all_squash.async.insecure.no_subtree_check.rw

When using the MCC when I attempt to mount this ( mnt/share ) I get a failed to mount error

Actually this is easier to see when I attempt to mount it on a Raspberry Pi:

pi@raspberrypi:~ $ sudo mount -a
mount.nfs: access denied by server while mounting 192.168.0.21:/home/wilcal/share

And this same Raspberry Pi mounts an NFS shared directory from an M7.1 platform
            
I've tried a LOT of things but I'm running out of guesses.
I guess I ask, has anyone set up an NFS directory share on M8 and how did they do that?

Thanks
Comment 1 William Kenney 2021-05-11 20:10:11 CEST
Working M7.1 NFS system:

MCC -> System -> Manage system services

nfs-idmapd       running checked on boot
nfs-mounted      running checked on boot
nfs-server       running checked on boot
nfs-utils        stopped checked on boot

Non-working M8 NFS system:

nfs-blkmap      stopped not checked on boot
nfs-convert     stopped not checked on boot
nfs-server      running checked on boot
nfs-domainname  stopped not checked on boot
Comment 2 William Kenney 2021-05-12 02:47:17 CEST
Using
Mageia-8-Live-Plasma-x86_64.iso
Which has nfs-utils preinstalled

I can easily mount a remote LAN Directory Share
But I can't share a directory with other systems
If I try I get a failed to mount error on the other systems
but they do see the share but can't mount it.
Comment 3 Herman Viaene 2021-05-12 08:48:07 CEST
I've done it, and it works OK. The main thing that is different in my setup is AFAICS:
The access * never worked for me, I put my LAN there.

CC: (none) => herman.viaene

Comment 4 William Kenney 2021-05-12 11:29:09 CEST
(In reply to Herman Viaene from comment #3)
> I've done it, and it works OK. The main thing that is different in my setup
> is AFAICS:
> The access * never worked for me, I put my LAN there.

So instead of "*" put 192.168.0.22 or whatever it is?
Comment 5 Herman Viaene 2021-05-12 13:48:03 CEST
yes, that does it for me.
Comment 6 Aurelien Oudelet 2021-05-12 18:31:27 CEST
Hi, thanks reporting this.

I don't have NFS share to test this.

Therefore, Len (tarazed) uses NFS shares too and I see good reports with NFS still running well upon updating kernel stuff...

Adding him for advice.

CC: (none) => ouaurelien, tarazed25

Comment 7 Len Lawrence 2021-05-12 22:35:16 CEST
I used to run through the setup using MCC and had no problems once I found settings that worked.  Access * always worked.
These days I keep a copy of /etc/fstab and in new installations copy and paste the relevant sections into /etc/fstab using vi.  The first step is always to set up /etc/hosts.  After editing fstab
# mount -a

So far that procedure has always worked - it takes a minute.  The relevant lines for me are:
$ cat fstab.lcl
spica:/volume1/castor /data/castor nfs hard,bg,users,noauto,exec 0 0
spica:/volume1/images /data/pollux nfs nosuid,rsize=8192,wsize=8192,soft 0 0
spica:/volume1/images/qa /home/lcl/qa nfs wsize=8192,rsize=8192,nosuid,soft 0 0
gomeisa:/home/lcl/topaz /home/lcl/pad nfs wsize=8192,rsize=8192,nosuid,soft 0 0
gomeisa:/home/lcl/.local /home/lcl/local nfs rsize=8192,nosuid,wsize=8192,soft 0 0
gomeisa:/home/lcl/ruby /home/lcl/quinckler nfs rsize=8192,nosuid,wsize=8192,soft 0 0
tmpfs /home/lcl/.cache tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=2048M 0 0 

where spica is my NAS drive (btrfs), gomeisa is the file server and /home/lcl/* the mount points.

Martin Whitaker was very helpful with the mount parameters.
Comment 8 Len Lawrence 2021-05-12 22:47:14 CEST
Regarding comment 7.  mounting .local as a file share is a bit iffy.  That needs to be deleted.  I use pad for configuration data for home grown programs most of the time.
Comment 9 William Kenney 2021-05-13 00:12:31 CEST
Many thanks to all working this bug.

I am mostly convinced that whatever is going on here, specifically with Mageia, is behind me. I have an M8 NFS directory server on real hardware that can be mounted by other M8 systems.

But having said that my Raspberry Pi platforms will not mount it. The Pi keeps saying it's locked out. So there seems to be a difference beween how M7.1 did this and M8.

For some reason I'm a little suspect of an M8 NFS directory server in a Vbox client. And I'm still tinkering with M8 Plasma Live-DVD which has nfs-utils preloaded.

Sorry again for finding all of this after release but this has worked so well for me over the years I never thought there'd be a problem. M8 vs M7.1 vs M6 NFS seem to differ some.
Comment 10 William Kenney 2021-05-13 00:16:51 CEST
Another thing of note. 

MCC: Network Sharing -> Share drives and directories using NFS
MCC: Share drives and directories using NFS
     Add -> Directory: /home/wilcal/share
            Access: *

There are two choices here. They are:
Access: *
Access: *.

Now if your like me with ageing eyes you don't see that little extra dot.
And it makes a difference.
Comment 11 Frank Griffin 2021-05-13 01:15:04 CEST
(In reply to Len Lawrence from comment #8)
> Regarding comment 7.  mounting .local as a file share is a bit iffy.  That
> needs to be deleted.  I use pad for configuration data for home grown
> programs most of the time.

.local should be fine.  I've mounted .thunderbird from a different system for years with no problem.  You just have to be careful not to run applications which write to the files therein simultaneously.  In my case, if I want to run thunderbird from one of the systems, I have to shut it down on the other first.  For .local, I imagine you'd have to log out of the desktop on one of the machines before logging in on the other.
Comment 12 William Kenney 2021-05-13 02:34:37 CEST
(In reply to Frank Griffin from comment #11)
> (In reply to Len Lawrence from comment #8)
> > Regarding comment 7.  mounting .local as a file share is a bit iffy.  That
> > needs to be deleted.  I use pad for configuration data for home grown
> > programs most of the time.
> 
> .local should be fine.  I've mounted .thunderbird from a different system
> for years with no problem.  You just have to be careful not to run
> applications which write to the files therein simultaneously.  In my case,
> if I want to run thunderbird from one of the systems, I have to shut it down
> on the other first.  For .local, I imagine you'd have to log out of the
> desktop on one of the machines before logging in on the other.

Thank you for contributing.
Very good discussion has come out of this.
I'll flag it as something to discuss in tomorrows QA Meeting
Comment 13 William Kenney 2021-05-15 02:23:04 CEST
I am going to set this bug to resolved.
My testing tells he that the M8 Plasma Live-DVD is not apprproate to set up a NFS Share
I was trying to use that as a test platform. Few people if any would use it this way.

Also the /etc/fstab in the Raspberry Pi platform does not seem to be able to mount
an M8 NFS share where it does mount an M7.1 share. A simple temp mount:

sudo mount 192.168.0.9:/home/wilcal/databank/  /home/pi/sherman_databank_share

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.