Bug 1187782 - YaST2 NFS server does not export file shares
YaST2 NFS server does not export file shares
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Network
Leap 15.3
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
E-mail List
https://trello.com/c/4udzh5Ga
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-06-28 14:41 UTC by Joel Miller
Modified: 2021-07-12 16:08 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
dgonzalez: needinfo? (jm-hotmail)


Attachments
screen shot from client machie (19.69 KB, image/png)
2021-07-07 16:30 UTC, Joel Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Miller 2021-06-28 14:41:42 UTC
At the conclusion of establishing a network share with YaST2 NFS server, one must manually export the share(s), either with the command exportfs -a (or -rav, etc.), or restart the server.  The Reference manual does not mention this in section 22.3 (https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-nfs.html#sec-nfs-configuring-nfs-server).

Could the exportfs function be added to the YaST2 process?
Comment 1 David Diaz 2021-07-07 11:01:17 UTC
Hi Joel!

Sorry for the delay. You're right, we could improve the situation for mentioned use case. I'll track the issue in our internal queue to be evaluated and prioritized. 

Thanks!
Comment 2 Joel Miller 2021-07-07 11:15:22 UTC
David -

Thank you.  And no rush - I suspect you have more critical items to resolve.  My submission was only a suggestion - there may have been design considerations that precluded adding exportfs to YaST.

This came up when I was trying to understand why YaST did not recognize the x-systemd.automount option; see https://forums.opensuse.org/showthread.php/556018-unknown-option-x-systemd-automount.  This issue was resolved by your colleague, Josef Reidinger, in https://bugzilla.suse.com/show_bug.cgi?id=1187781.

I sincerely appreciate your assistance and the opportunity to participate.

Joel
Comment 3 David Diaz 2021-07-07 13:09:38 UTC
Joel, thanks for the understanding and the new input. 

Now, I'm a little bit confused because taking a look at the code I can see that the nfs-server service[1] is being restarted [2] on each write.

I even tested myself by

* Checking the status of nfs-server service

>  ➜ systemctl status nfs-server        
> ● nfs-server.service - NFS server and services
>      Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
>     Drop-In: /usr/lib/systemd/system/nfs-server.service.d
>              └─options.conf
>              /run/systemd/generator/nfs-server.service.d
>              └─order-with-mounts.conf
>     Active: active (exited) since Wed 2021-07-07 12:09:17 WEST; 1h 45min ago

* Opening the YaST NFS Server module
*  Keeping Start selected in the first screen
* Go Next
* Add Directory
* Finish
* Check the nfs-server service status again

>  ➜ systemctl status nfs-server
> ● nfs-server.service - NFS server and services
>      Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
>     Drop-In: /usr/lib/systemd/system/nfs-server.service.d
>              └─options.conf
>              /run/systemd/generator/nfs-server.service.d
>              └─order-with-mounts.conf
>      Active: active (exited) since Wed 2021-07-07 13:58:21 WEST; 16s ago

And as far as I can see, the service was restarted. 

Did I misunderstand the issue?


[1] https://github.com/yast/yast-nfs-server/blob/4cd97f792b2ae0b088740cba0250378927de034c/src/modules/NfsServer.rb#L22

[2] https://github.com/yast/yast-nfs-server/blob/4cd97f792b2ae0b088740cba0250378927de034c/src/modules/NfsServer.rb#L313
Comment 4 Joel Miller 2021-07-07 15:54:48 UTC
David -

Perhaps I'm mistaken.  I agree that the nfs server is restarted by YaST and that /etc/exports is updated to the exports currently listed in the YaST module.

The error I encountered in Dolphin on the client machine was "mount.nfs: access denied by server while mounting."  See https://forums.opensuse.org/showthread.php/556018-unknown-option-x-systemd-automount?p=3043678#post3043678.  The share was accessible on the client once I entered exportfs -rav on the server machine.  This was long after I completed the NFS server process, but before rebooting.   See https://forums.opensuse.org/showthread.php/556018-unknown-option-x-systemd-automount?p=3043291#post3043291.  I tried the exportfs command after reading this Red Hat post: https://access.redhat.com/solutions/3773891.  Although /etc/exports is updated as one completes the module, must one reboot to export the shares so that they propagate to the other machines on the network?

I believe what I see on the github page is the code for the YaST NFS server module. It does not appear to have the command exportfs.  Is there some other code that exports the shares?

My initial attempts to recreate what I experienced last month were not helpful; in fact, they threw off other errors - all likely ones I caused.  I will further review the excerpts on gitbub, do some further digging and then get back to you.

Joel
Comment 5 Joel Miller 2021-07-07 16:30:29 UTC
Created attachment 850834 [details]
screen shot from client machie

In my attempt to recreate the share export issue, I saw this error in YaST on the client machine (see the attached image).  I'm not sure if this is same one described in the opensuse forum.
Comment 6 Joel Miller 2021-07-07 16:32:46 UTC
David -

Can one edit a comment after submission?  I thought I did this once, but can't remember how I did it.

Joel
Comment 7 Joel Miller 2021-07-07 21:06:59 UTC
David -

One additional note.  In the situation discussed on the opensuse forum, I had manually entered the share mount in fstab - not in NFS Client.  I did so by literally copying the fstab entry for one of the pre-existing share mounts; see the code in the first post at https://forums.opensuse.org/showthread.php/556018-unknown-option-x-systemd-automount?p=3043273#post3043273.
Comment 8 David Diaz 2021-07-09 06:24:52 UTC
(In reply to Joel Miller from comment #6)
> David -
> 
> Can one edit a comment after submission?  I thought I did this once, but
> can't remember how I did it.
> 
> Joel

Sadly, I would say no, you can't.
Comment 9 David Diaz 2021-07-09 06:27:14 UTC
I haven't been able to test it yet. It's in my to-do list :)
Comment 10 Josef Reidinger 2021-07-09 07:04:53 UTC
Well, what can help us is logs from nfs server when that access denied happen.

So ideally systemd journal obtained with

sudo journalctl -b > /tmp/journal.txt

and yast logs to see if something goes wrong

save_y2logs

This way we can verify that restart happens properly and also why nfs server complain about access, so we can discuss it with nfs server maintainer.
Comment 11 Joel Miller 2021-07-09 09:21:41 UTC
(In reply to David Diaz from comment #9)
> I haven't been able to test it yet. It's in my to-do list :)

David -

Does the test you mention in this comment refer to whether the NFS server performs an export function (in addition to writing to /etc/exports)?

I have been reading up on this subject and it appears that exports may not instantly reach all of the clients on a network, perhaps not surprising given how machines configure themselves on boot-up, network registration and log-in, permissions, off-line considerations, etc.  Perhaps it takes at least one re-boot on all all devices before the exports in the server's /etc/exports list reaches all of the clients.

Joel
Comment 12 Joel Miller 2021-07-11 15:59:31 UTC
Josef -

The denial of access is on the client machine, not the server.

Here is the workflow sequence:

1. on the server machine, created a new nfs share /z/f in YaST and followed the dialog through to completion.  /etc/exports now shows the new nfs share.  No errors on the server; turned to the client machine.

2. on the client machine, edited fstab on the client for the new share, using the same syntax as used for the currently-working preexisting shares.

    code: 192.168.1.223:/z/f/   mnt/m9nfs/f   nfs   noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,x-systemd.idle-timeout=5min  0  0

(Since I manually edited fstab, I did not receive the x-systemd.automount unknown option error; that only occurred when I went into the YaST NFS client dialog.)

3. added folder "f" to mnt/m9fs.

4. opened Dolphin and tried to access the new share "f" - Dophin reported, "mount.nfs: access denied by server while mounting."

At the moment I need to complete a critical project and hope to then return to this issue.

Joel
Comment 13 David Diaz 2021-07-12 07:53:05 UTC
Thanks a lot for the steps to reproduce, Joel.
Comment 14 David Diaz 2021-07-12 15:52:19 UTC
(In reply to Joel Miller from comment #12)
> Josef -
> 
> The denial of access is on the client machine, not the server.
> 
> Here is the workflow sequence:
> 
> 1. on the server machine, created a new nfs share /z/f in YaST and followed
> the dialog through to completion.  /etc/exports now shows the new nfs share.
> No errors on the server; turned to the client machine.
> 
> 2. on the client machine, edited fstab on the client for the new share,
> using the same syntax as used for the currently-working preexisting shares.
> 
>     code: 192.168.1.223:/z/f/   mnt/m9nfs/f   nfs  
> noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,x-
> systemd.idle-timeout=5min  0  0
> 
> (Since I manually edited fstab, I did not receive the x-systemd.automount
> unknown option error; that only occurred when I went into the YaST NFS
> client dialog.)
> 
> 3. added folder "f" to mnt/m9fs.
> 
> 4. opened Dolphin and tried to access the new share "f" - Dophin reported,
> "mount.nfs: access denied by server while mounting."
> 
> At the moment I need to complete a critical project and hope to then return
> to this issue.
> 
> Joel

I tried to reproduce the issue again by creating some exports in the server (my host machine) and then adding manually the entries in the /etc/fstab as described in comment #12 (and using the same options) in the guest (an openSUSE Tumbleweed with KDE Desktop installed in a virtual machine).

> 10.0.0.1:/var/log        /home/dgdavid/logs      nfs    noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,x-systemd.idle-timeout=5min   0  0

"Unfortunately", the only error I got from Dolphin is 

> mount.nfs: failed to prepare mount: Operation not permitted

when not using the "user" option. Adding it, Dolphin was able to mount the export right away after editing the /etc/fstab file as root user.

> 10.0.0.1:/var/log        /home/dgdavid/logs      nfs    user,noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,x-systemd.idle-timeout=5min   0  0

So, still thinking that maybe there is something I didn't understand well or there are other reasons why it is failing for Joel.

Anyway, somehow I had come to the conclusion that adding the execution of the `exportfs -a` command proposed in comment #1 might not hurt... until I realized that due to the service definition in the systemd unit file for nfs-server the `exportfs -au`, `exportfs -f`, and `exportfs -r` commands are already executed when restarting the service since

> 
> ➜ man systemd.service
> 
> ...
>
>  Service restart requests are implemented as stop operations followed by start
>  operations. This means that ExecStop= and ExecStopPost= are executed during a service
>  restart operation.
>
> ...
> 

and

> 
> ➜ cat /usr/lib/systemd/system/nfs-server.service
> 
> ...
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStartPre=-/usr/sbin/exportfs -r
> ExecStart=/usr/sbin/rpc.nfsd
> ExecStop=/usr/sbin/rpc.nfsd 0
> ExecStopPost=/usr/sbin/exportfs -au
> ExecStopPost=/usr/sbin/exportfs -f
> 
> ExecReload=-/usr/sbin/exportfs -r
>
> ...
> 

So, I'm not sure if there is something we can do or even if the problem is the reported problem is really related to the `exportfs` command and/or how YaST restart the nfs-server service.
Comment 15 Joel Miller 2021-07-12 16:08:11 UTC
David -

Thanks.  I will look into this.

Joel