NFS Problems with Mounting shares
-
- OMV 3.x
- mipi
-
-
-
According to this nfs mail list the fsid option is no longer required in case you wanted to differentiate mounting in between nfsv4 and nfsv321.
http://comments.gmane.org/gmane.linux.nfs/45353
a nfs4 we usually do ip:/sharename nfsv321 is ip:/export/sharename. At least in omv that was the case following debian nfs guidelines
@mipi if you want to keep mounting as nfsv4 (as i see you're doing) just add the 'export' string plus the type of fs (optional i guess)...so,
NFSv4
mount omv:/export/downloads Downloads
Now NFSv321 will have to explicitly call the version in the client options
mount -o nfsvers=3 omv:/export/downloads Downloads
This was tested debian against debian. If your client is some other reduced flavours of linux don't know how i'll behave (busybox)
-
Sry this was not the whole Story, Normallly I mount my shares in fstab (using Ubuntu 16.04)
Code
Alles anzeigen### 192.168.178.20 Userdaten 192.168.178.20:/home/pi /home/pi/Dokumente nfs rw 0 0 192.168.178.20:/home/pi /home/pi/Daten nfs rw 0 0 192.168.178.20:/media/photo /home/pi/Bilder nfs rw 0 0 192.168.178.20:/media/music /home/pi/Musik nfs rw 0 0 192.168.178.20:/media/video /home/pi/Videos nfs rw 0 0 192.168.178.20:/media/books /home/pi/Buecher nfs rw 0 0 192.168.178.20:/public /home/pi/Public nfs rw 0 0 192.168.178.20:/downloads /home/pi/Downloads nfs rw 0 0 192.168.178.20:/images /home/pi/images nfs rw 0 0 #192.168.178.20:/data/sabnzbd /home/pi/sabnzbd nfs rw 0 0
All these mounts are empty while the exports are present
Codeshowmount -e omv Export list for omv: /export 192.168.178.0/24 /export/media 192.168.178.0/24 /export/fhem 192.168.178.0/24 /export/images 192.168.178.0/24 /export/public 192.168.178.0/24 /export/downloads 192.168.178.0/24 /export/home 192.168.178.0/24
sudo mount -a
[sudo] Passwort für pi:
mount.nfs: access denied by server while mounting 192.168.178.20:/home/pi
mount.nfs: access denied by server while mounting 192.168.178.20:/home/pi
mount.nfs: access denied by server while mounting 192.168.178.20:/media/photo
mount.nfs: access denied by server while mounting 192.168.178.20:/media/music
mount.nfs: access denied by server while mounting 192.168.178.20:/media/video
mount.nfs: access denied by server while mounting 192.168.178.20:/media/books
mount.nfs: access denied by server while mounting 192.168.178.20:/public
mount.nfs: access denied by server while mounting 192.168.178.20:/downloads
mount.nfs: access denied by server while mounting 192.168.178.20:/images
mount.nfs: access denied by server while mounting 192.168.178.20:/fhem
sudo mount -a -
add the "export" string to the remote path
-
It works - thanks
Why have it changed between, two minor updates? While trying around I came across another issue
Code### fhem-Server 192.168.178.20:/export/fhem /home/pi/fhem nfs rw 0 0 192.168.178.20:/export/fhem /home/pi/fhem nfs4 rw,_netdev,auto 0 0
What is the difference / benefit of using nfs4 / these special entries, shall I change all the entries?
Bye Micha from Berlin
-
As per home usage I see no difference in between 4 and older versions. You can do you're own research, you were already using nfsv4 so everything stays the same.
-
Hi,
Picking up on this: Thanks for the information everyone provided on this issue so far. Working on mounting openmediavault 3.0.46 NFS shares from various clients that use NFS version 3 I have the same issue but have a restriction so I can't add "/exports/"
Via nfs version 4 it works nicely:
$ showmount -e nas
...
/export/logs *
...and logs can be mounted this way:
$ mount nas:/logs /mnt/test123/tmpBut an NFS version 3 client cannot:
$ mount nas:/logs /var/tmp/test
nfs mount: nas:/logs: Permission deniedYes, it works by inserting /export/ as you guys said in the thread:
$ mount nas:/export/logs /var/tmp/test
but I must get it to work with the short path on NFS version 3 because of a large number of NFS version 3 clients that use automount (which inserts the 'export' if it's there) in combination with programs that use a hardcoded NFS path.
Question: How can offer the short path to all clients? I found an ugly "hack" (see below) but would like to do it properly in the GUI.
the ugly workaround is:
on OMV:
$ mkdir /logs
mount this new folder in /etc/fstab:
/rz2pool/logs/logs /logs none bind 0 0
add the new folder to /etc/exports:
/logs *(rw,subtree_check,secure,no_root_squash)
(this hack survives a reboot)Thanks
-
This commit has been reverted, It should be working as usual like before.
-
I think Roccur have to Update to >= 3.0.49, right?
-
I think Roccur have to Update to >= 3.0.49, right?
Hi @mipi / @subzero79 - I just upgraded to 3.0.50 (Erasmus) and it does not make a difference: If you use NFS version 3 you still have to specify /export/ in front.
-
So, for those of us still on Stoneburner, how do we resolve this? This has worked flawlessly between two OMV instances where one shares via NFS and the other accesses the share via Remote Share plugin. Now with recent updates it is all broken. Please advise the best path to resolve this without having to go to 3.0 at the moment.
UPDATE: So the odd thing, I removed the remote share plugin but the definition is still inside the /etc/fstab file between the OMV area. I am just going to leave it there since it does what it has to do but this all seems a mess at the moment.
-
Well, it is gone now. I have no idea why.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!