David Diaz changed bug 1187782
What Removed Added
Flags   needinfo?(jm-hotmail@hotmail.com)

Comment # 14 on bug 1187782 from
(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: