https://bugzilla.suse.com/show_bug.cgi?id=1187782 Chenzi Cao changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |mvidner@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c1 David Diaz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgonzalez@suse.com --- Comment #1 from David Diaz --- 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! -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c2 --- Comment #2 from Joel Miller --- 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-a.... 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 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c4 --- Comment #4 from Joel Miller --- 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-a.... 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-a.... 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 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c6 --- Comment #6 from Joel Miller --- David - Can one edit a comment after submission? I thought I did this once, but can't remember how I did it. Joel -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c8 --- Comment #8 from David Diaz --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c10 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jm-hotmail@hotmail.com, | |jreidinger@suse.com Flags| |needinfo?(jm-hotmail@hotmai | |l.com) --- Comment #10 from Josef Reidinger --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c12 --- Comment #12 from Joel Miller --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 https://bugzilla.suse.com/show_bug.cgi?id=1187782#c14 David Diaz changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jm-hotmail@hotmai | |l.com) --- Comment #14 from David Diaz --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187782 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jm-hotmail@hotmai | |l.com) | -- You are receiving this mail because: You are on the CC list for the bug.