Description of problem: Something seems to have changed M8 -> M9 using the simple NFS mount command [root@localhost wilcal]# mount source target M8 -- [root@localhost wilcal]# uname -a Linux localhost 5.15.98-desktop-1.mga8 #1 SMP Sat Mar 4 12:16:27 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux [root@localhost wilcal]# urpmi --auto nfs-utils Package nfs-utils-2.5.2-2.mga8.x86_64 is already installed [root@localhost wilcal]# mount 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home 192.168.0.12 is a QNAP NAS source with NFS setup /home/wilcal//home/wilcal/nas_wilcal_home is the local target directory Using this simple command on M8 it works every time. I've been using it for years. Even on M7 umount /home/wilcal/nas_wilcal_home ( unmounts hjust fine ) First time using the mount command on M8: [root@localhost wilcal]# mount 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service. run unmount Subsequent mount commands result in the following: [root@localhost wilcal]# mount 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home [root@localhost wilcal]# so in M8 you can mount and unmount without problems If you do a reboot you'll get the "Created symlink" message again, but just the once at first time. M9 -- [root@localhost wilcal]# uname -a Linux localhost 6.2.8-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 23:33:18 UTC 2023 x86_64 GNU/Linux [root@localhost wilcal]# urpmi --auto nfs-utils Package nfs-utils-2.6.2-2.mga9.x86_64 is already installed Using the same process on M9 I get the following error: [root@localhost wilcal]# mount 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount.nfs: Protocol not supported
On a Raspberry Pi 400, 32-bit OS on a 64-bit platform ( updated 23mar23 ) pi@raspberrypi:~ $ uname -a Linux raspberrypi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux pi@raspberrypi:~ $ sudo apt-get -y install nfs-common nfs-common is already the newest version (1:1.3.4-2.5+deb10u1). sudo mount 192.168.0.12:/public/wilcal_home/ /home/pi/nas_wilcal_home sudo umount /home/pi/nas_wilcal_home Both work absolutely just fine.
Thanks for the report, Bill. Have you sounded other QA people about this (qa-discuss)? I cannot try this to look into, so assigning directly to Guillaume for nfs.
Source RPM: (none) => nfs-utils-2.6.2-2.mga9.src.rpmSummary: NFS mount command M8 -> M9 has changed => NFS mount command M8 -> M9 has changed. M9 gives error "mount.nfs: Protocol not supported"Assignee: bugsquad => guillomovitchCC: (none) => lewyssmith
You can first check which version of the protocol is supported by your server: rpcinfo 192.168.0.12 | grep nf You can then use -v flag for additional output: mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal And adjust your mount option accordingly if auto-negociation fails.
(In reply to Guillaume Rousse from comment #3) Many thanks to Guillaume Rousse for your assistance here This in depth look at an NFS mount is new to me. Commands on test: mount 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home umount /home/wilcal/nas_wilcal_home unsuccessful M9 --------------- mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount.nfs: timeout set for Sat Mar 25 06:07:16 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.12,clientaddr=192.168.0.116' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.0.12,clientaddr=192.168.0.116' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=192.168.0.12,clientaddr=192.168.0.116' mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported successful M8 ------------- mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount.nfs: timeout set for Sat Mar 25 06:27:26 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.12,clientaddr=10.0.2.15' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.0.12,clientaddr=10.0.2.15' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=192.168.0.12,clientaddr=10.0.2.15' mount.nfs: mount(2): Protocol not supported Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service. mount.nfs: trying text-based options 'addr=192.168.0.12' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.0.12 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.0.12 prog 100005 vers 3 prot UDP port 30000 Something with creating a symlink, or not?
Bill, you did not do Guillaume's first suggestion: (In reply to Guillaume Rousse from comment #3) > You can first check which version of the protocol is supported by your > server: > rpcinfo 192.168.0.12 | grep nf
It doesn't matter much, verbose output is enough to see the NFS server doesn't support NFS 4. Either use -o vers=3 when running the mount command, or configure /etc/nfsmount.conf to use version 3 with this specific mount point.
(In reply to Guillaume Rousse from comment #3) > You can first check which version of the protocol is supported by your > server: > rpcinfo 192.168.0.12 | grep nf [root@localhost wilcal]# rpcinfo 192.168.0.12 | grep nf 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100227 2 tcp 0.0.0.0.8.1 nfs_acl superuser 100227 3 tcp 0.0.0.0.8.1 nfs_acl superuser 100003 2 udp 0.0.0.0.8.1 nfs superuser 100003 3 udp 0.0.0.0.8.1 nfs superuser 100227 2 udp 0.0.0.0.8.1 nfs_acl superuser 100227 3 udp 0.0.0.0.8.1 nfs_acl superuser 100003 2 tcp6 ::.8.1 nfs superuser 100003 3 tcp6 ::.8.1 nfs superuser 100227 2 tcp6 ::.8.1 nfs_acl superuser 100227 3 tcp6 ::.8.1 nfs_acl superuser 100003 2 udp6 ::.8.1 nfs superuser 100003 3 udp6 ::.8.1 nfs superuser 100227 2 udp6 ::.8.1 nfs_acl superuser 100227 3 udp6 ::.8.1 nfs_acl superuser
TA! TA! Commands on test: mount -o vers=3 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home umount /home/wilcal/nas_wilcal_home Both worked. I gotta think about this for awhile. Do some more testing. What happened here? Did we move to Ver 4 and not QNAP? Or is this something common? There's a LOT of QNAP NAS's out there. Thanks all
NFSv4 exists since 2013. You may ask QNAP support why they still don't support it.
In most cases it is an improperly set up QNAP as nearly all of their products support NFSv4. From their support page: A: Please go to theNAS management page > Control Panel > Network & File Services > Win/Mac/NFS page, choose NFS Services tab and tick the checkbox of Enable NFS v4 Service and then click on Apply button to enable NFS v4 service
Many thanks to all for getting through this. This setup issue may extend farther then just QNAP.
(In reply to sturmvogel from comment #10) > In most cases it is an improperly set up QNAP as nearly all of their > products support NFSv4. From their support page: > > A: Please go to theNAS management page > Control Panel > Network & File > Services > Win/Mac/NFS page, > choose NFS Services tab and tick the checkbox of Enable NFS v4 Service and > then click on Apply button to enable NFS v4 service QNAP NAS management page > Control Panel > Network & File Services > Win/Mac/NFS page, NFS Services tab, NFS v4 Service enabled mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount.nfs: timeout set for Sun Mar 26 14:14:02 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.12,clientaddr=192.168.0.116' mount.nfs: mount(2): No such file or directory mount.nfs: mounting 192.168.0.12:/public/wilcal_home/ failed, reason given by server: No such file or directory no mount mount -v -o vers=3 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home mount.nfs: timeout set for Sun Mar 26 14:00:47 2023 Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service. mount.nfs: trying text-based options 'vers=3,addr=192.168.0.12' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.0.12 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.0.12 prog 100005 vers 3 prot UDP port 30000 mounts umount /home/wilcal/nas_wilcal_home works all the time
This info should be in Erratas
Keywords: (none) => FOR_ERRATA9
(In reply to katnatek from comment #13) > This info should be in Erratas Many thanks to all for helping me wrestle with this.
> mount -v 192.168.0.12:/public/wilcal_home/ /home/wilcal/nas_wilcal_home > mount.nfs: timeout set for Sun Mar 26 14:14:02 2023 > mount.nfs: trying text-based options > 'vers=4.2,addr=192.168.0.12,clientaddr=192.168.0.116' > mount.nfs: mount(2): No such file or directory > mount.nfs: mounting 192.168.0.12:/public/wilcal_home/ failed, reason given > by server: No such file or directory > no mount NFSv4 exports a virtual filesystem, independently from its actual location. This should work: mount -v 192.168.0.12:/ /home/wilcal/nas_wilcal_home If it doesn't, check what your server actually export, and correct the previous command accordingly: showmount 192.168.0.12 -e
(In reply to Guillaume Rousse from comment #15) > NFSv4 exports a virtual filesystem, independently from its actual location. > This should work: > mount -v 192.168.0.12:/ /home/wilcal/nas_wilcal_home OOOooooo that's gonna be a really really big mount Almost 4TB It's a RAID 5, four 4TB Seagate Ironwolf drives. Just under 11TB of available space > If it doesn't, check what your server actually export, and correct the > previous command accordingly: > showmount 192.168.0.12 -e [root@localhost wilcal]# showmount 192.168.0.12 -e Export list for 192.168.0.12: /Public *
Added info in Erratas , please give a check https://wiki.mageia.org/en/Mageia_9_Errata#Mounting_NFSv3_shares
Keywords: FOR_ERRATA9 => IN_ERRATA9
(In reply to William Kenney from comment #16) > (In reply to Guillaume Rousse from comment #15) > > > NFSv4 exports a virtual filesystem, independently from its actual location. > > This should work: > > mount -v 192.168.0.12:/ /home/wilcal/nas_wilcal_home > > OOOooooo that's gonna be a really really big mount > Almost 4TB > It's a RAID 5, four 4TB Seagate Ironwolf drives. > Just under 11TB of available space '/' here is the root of the exported filesystem, not the root of the actual filesystem. NFSv4 hide underlying server setup from the clients. > > If it doesn't, check what your server actually export, and correct the > > previous command accordingly: > > showmount 192.168.0.12 -e > > [root@localhost wilcal]# showmount 192.168.0.12 -e > Export list for 192.168.0.12: > /Public * If your NFS exports '/Public', you should be able to either mount '/' or '/public'.
(In reply to katnatek from comment #17) > Added info in Erratas , please give a check > > https://wiki.mageia.org/en/Mageia_9_Errata#Mounting_NFSv3_shares Looks great, thanks.
Some additional retesting this today tells me that we can change this bug to "RESOLVED" Many thanks to all.
Status: NEW => RESOLVEDResolution: (none) => FIXED