Jump to content

NFS protocol not supported?


tony013

Recommended Posts

Hi,

 

I just updated my armbian current to 5.10.35 and I'm quite excited, as pwm and gpio works as with LE :)

Then I tried to mount some nfs-shares from nas. Usually I only have to install nfs-common.

I did that on armbian, but when I try to mount a share, I get the error message, that nfs protocol (version) is not supported.

 

The used command work on every other system I have (desktop and rockpi).

I just use 'nfs' as filesystem type - no version specified/requested.

 

Is there something special on armbian, to have nfs support enabled?

Link to comment
Share on other sites

1 hour ago, tony013 said:

ust updated my armbian current to 5.10.35 and I'm quite excited, as pwm and gpio works as with LE :)

Then I tried to mount some nfs-shares from nas. Usually I only have to install nfs-common.

I did that on armbian, but when I try to mount a share, I get the error message, that nfs protocol (version) is not supported.

 

The used command work on every other system I have (desktop and rockpi).

I just use 'nfs' as filesystem type - no version specified/requested.

 

Is there something special on armbian, to have nfs support enabled?


that is weird..

can you do the following

zgrep -i nfs /proc/config.gz


and also armbianmontor -u

Link to comment
Share on other sites

5 hours ago, tony013 said:

did that on armbian, but when I try to mount a share, I get the error message, that nfs protocol (version) is not supported.


what's your mount target.... for grins try added -o vers=3

 

 

Link to comment
Share on other sites

2 hours ago, lanefu said:

what's your mount target.... for grins try added -o vers=3

 

For what it's worth, I've hit this error when trying to mount a NFS share from a Windows system (no idea how it was set up), and had to use NFS v2 for it to work.

Link to comment
Share on other sites

Thank you all for your support!

 

vor 7 Stunden schrieb lanefu:

can you do the following



zgrep -i nfs /proc/config.gz

Oh, didn't know, that config is available that way (on my desktop debian it is not)

 

Here's the result:

CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_FUNCTIONFS_ETH=y
CONFIG_USB_FUNCTIONFS_RNDIS=y
CONFIG_USB_FUNCTIONFS_GENERIC=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_KERNFS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
CONFIG_NFS_V3=m
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
CONFIG_NFS_SWAP=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
CONFIG_NFS_V4_1_MIGRATION=y
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFS_DISABLE_UDP_SUPPORT=y
CONFIG_NFS_V4_2_READ_PLUS=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_PNFS=y
CONFIG_NFSD_BLOCKLAYOUT=y
CONFIG_NFSD_SCSILAYOUT=y
CONFIG_NFSD_FLEXFILELAYOUT=y
# CONFIG_NFSD_V4_2_INTER_SSC is not set
CONFIG_NFSD_V4_SECURITY_LABEL=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y

 

And this is "grep -i nfs /boot/config-5.10.0-0.bpo.3-amd64" from my desktop debian

CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_FUNCTIONFS_ETH=y
CONFIG_USB_FUNCTIONFS_RNDIS=y
CONFIG_USB_FUNCTIONFS_GENERIC=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_KERNFS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
CONFIG_NFS_V3=m
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
CONFIG_NFS_SWAP=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFS_DISABLE_UDP_SUPPORT=y
# CONFIG_NFS_V4_2_READ_PLUS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_PNFS=y
CONFIG_NFSD_BLOCKLAYOUT=y
# CONFIG_NFSD_SCSILAYOUT is not set
# CONFIG_NFSD_FLEXFILELAYOUT is not set
# CONFIG_NFSD_V4_2_INTER_SSC is not set
CONFIG_NFSD_V4_SECURITY_LABEL=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y

 

vor 7 Stunden schrieb lanefu:

and also armbianmontor -u

I beg your pardon, but I'm too stupid for that tool.

I read a lot about it (in other threads), skimmed the docs for it, but I don't know, what to enter, when it asks for a target.

So if you tell me what output you want, I could deliver any on my own.

I know my debian well - as a user. Not as a developer.

 

vor einer Stunde schrieb tparys:

I've hit this error when trying to mount a NFS share from a Windows system

I don't have/use any windows systems. My PCs run all debian stable without any experiments.

Only with rockpi I started to use others and find a usable base ...

 

vor 3 Stunden schrieb lanefu:

what's your mount target...

I don't understand your question.

I have two rockpi sata towers, one runs armbian multimedia legacy with emmc and boot from usb-drive, the other (not assembled yet) is my testbox, where I can switch sdcards.

 

In this case, armbian multimedia legacy is the nfs server and armbian current was the client (target?)

Link to comment
Share on other sites

49 minutes ago, tony013 said:

when it asks for a target.

Target?

armbianmontor -u will provide you with a link to a website where the debug logs have been pushed to. If your board is not connected to the internet or there are other issues it should tell you to use -U instead of -u to output everything to stdout so you can paste it somewhere else.

Link to comment
Share on other sites

18 hours ago, tony013 said:

Is there something special on armbian, to have nfs support enabled?

 

There are a number of issues with the numerous versions of nfs, locking, architecture and export path on server with nfsV4 ... and I wouldn't trust error messages.

 

For example "protocol not supported" can be emitted because of the share path semantic :

 

From : https://wiki.archlinux.org/title/NFS/Troubleshooting#mount.nfs:_Protocol_not_supported

 

 

mount.nfs: Protocol not supported

This error occurs when you include the export root in the path of the NFS source. For example:

# mount SERVER:/srv/nfs4/media /mnt mount.nfs4: Protocol not supported

Use the relative path instead:

# mount SERVER:/media /mnt

 

I have had some troubles in the past with export path and nfsV4 and it works at present although my configuration is not supposed to be correct ?!?

Link to comment
Share on other sites

vor 10 Stunden schrieb Werner:

armbianmontor -u will provide you with a link to a website where the debug logs have been pushed to.

Thank you, Werner, for the explanation!

Patience is not my strong point. So I killed the program before it could tell me any link.

I thought, I have to enter some address or path ...

Being more patient, it works ;)

 

vor 14 Stunden schrieb lanefu:

for grins try added -o vers=3

does not change anything.

 

vor einer Stunde schrieb arox:

There are a number of issues with the numerous versions of nfs, locking, architecture and export path on server with nfsV4 ... and I wouldn't trust error messages.

Hm, I do not want to use version 4, nor do i have an export root stored anywhere. Thus it is difficult for me to assign the error to this category.

 

anyway ...

 

... since the error only occurs when both server and client are running armbian, I had a suspicion.
So I started the client (armbian recent) with ssh connection to my main machine. When I then turned on the NAS, the ssh connection was interrupted with the following error message:
"Connection to ... port 22: Broken pipe"

When I then looked at the list of active machines, only the NAS was listed. The client (with armbian) was gone.

Could it be, that the MAC address is generated by the operating system and thus two different machines get the same MAC address?

 

That would explain a lot.

Link to comment
Share on other sites

After some further research - it looks like armbian generates mac-address from cpuid - but rockpi has no cpuid ...

 

excerpt from ifconfig:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6e:e4:fe:d4:82:6d brd ff:ff:ff:ff:ff:ff

 

Is there a way to fake/set/overwrite static part from cpuid or cpuid ?

Link to comment
Share on other sites

26 minutes ago, tony013 said:

After some further research - it looks like armbian generates mac-address from cpuid - but rockpi has no cpuid ...

 

excerpt from ifconfig:



1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6e:e4:fe:d4:82:6d brd ff:ff:ff:ff:ff:ff

 

Is there a way to fake/set/overwrite static part from cpuid or cpuid ?

 

Hum  !

 

Is address 6e:e4:fe:d4:82:6d a valid mac-address ?

 

It seems to me that the first bit of first octet shouln't be 1 because it is reserved to multicast addresses.

 

https://communities.vmware.com/t5/VMware-Fusion-Discussions/The-first-byte-of-the-MAC-address-cannot-bit-odd/td-p/1218107

 

7 minutes ago, arox said:

 

Hum  !

 

Is address 6e:e4:fe:d4:82:6d a valid mac-address ?

 

It seems to me that the first bit of first octet shouln't be 1 because it is reserved to multicast addresses.

 

https://communities.vmware.com/t5/VMware-Fusion-Discussions/The-first-byte-of-the-MAC-address-cannot-bit-odd/td-p/1218107

 

 

Sorry, my mistake, 6e is odd !!!

 

5 minutes ago, arox said:

Sorry, my mistake, 6e is odd !!!

 

Sorry, it is even so first bit 0. I go to bed ...

Link to comment
Share on other sites

vor 2 Minuten schrieb arox:

6e is odd !!!

I don't think, that my dhcp-server does validate the mac-address. I guess, it takes the number as is and uses it as token ...

 

anyway: looks like I found the problem.

I guess, any linux has some individual hardcoded portion ...

this is output from twisteros:

 eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
	    link/ether ea:69:c3:92:45:fc brd ff:ff:ff:ff:ff:ff

its different to armbian native - but also constant - so two boxes with twister would fail too

Link to comment
Share on other sites

Hi,

 

having identified the evil, I found lots of postings about this issue.

Unfortunately the given workarounds don't work.

 

  • setting ethaddr in /boot/armbianEnv.txt does not change anything
  • same with modifying /etc/network/interfaces - no effect.

What worked with armbian current (kernel 5.10.35) is changing configuration of Network-Manager.

That configuration can be found at /etc/Networkmanager/system-connections

I have a file-entry like this: 'Wired connection 1.nmconnection'. Format is common ini-file format of linux.

There's a group called [ethernet], which contains an entry "cloned-mac-address", which gets used on every  reboot.

 

Changing that number, changes mac-address and for so the address received from dhcp server.

 

@developers

As there are so many postings regarding this issue, what about adding a "network" section to "Troubleshooting" of armbian documentation?

Link to comment
Share on other sites

> setting ethaddr in /boot/armbianEnv.txt does not change anything

 

This sets a u-boot environment variable. It is up to the boot script used for your board whether or not anything is done with it. What boot script you're using is a mystery as you've not provided any information about your board (armbianmonitor -u).

 

>same with modifying /etc/network/interfaces - no effect.

 

Per "man 5 interfaces", the option is "hwaddress". Whether or not this takes effect is determined by what network software is running (NetworkManager or ifupdown). Given that poking NetworkManager files created a change, it's probably the former.

 

> Just for sake of documentation: setting mac address in /etc/network/interfaces works on TwisterOS

 

And it's probably using ifupdown. You can switch if you'd like. I bet it works on Armbian too, but you need to be running it first.

 

$ sudo systemctl stop NetworkManager
$ sudo systemctl disable NetworkManager
$ sudo systemctl start networking 
$ sudo systemctl enable networking

 

Link to comment
Share on other sites

vor 5 Stunden schrieb tparys:

What boot script you're using is a mystery as you've not provided any information about your board (armbianmonitor -u)

Just wanted to upload that information for you, but ...

root@rockpi-4a:~# armbianmonitor -u
System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for.

root@rockpi-4a:~# ping armbian.com
PING armbian.com(stuff.armbian.com (2605:7900:20::5)) 56 data bytes
64 bytes from stuff.armbian.com (2605:7900:20::5): icmp_seq=1 ttl=51 time=166 ms
64 bytes from stuff.armbian.com (2605:7900:20::5): icmp_seq=2 ttl=51 time=164 ms
64 bytes from stuff.armbian.com (2605:7900:20::5): icmp_seq=3 ttl=51 time=164 ms
^C
--- armbian.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 164.301/164.886/166.041/0.816 ms
root@rockpi-4a:~# armbianmonitor -u
System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for.

So - its not only for being impatient, the tool seems not to work as it should - or I'm stil to dumb to use it. The ping is just to proove, that I have internet access enabled.

I attached the output to this post

vor 5 Stunden schrieb tparys:

And it's probably using ifupdown. You can switch if you'd like.

That's not the question.

As a common user, you won't care which tool provides network support as long as the network works. So I guess, its not common to know about these options.

Having a problem - you search around and most (at least what I did) was trial and error.

Therefore I would have been happy to find a network section in armbian documentation which lists the issues or links to related forum discussions.

 

by the way: mac-address of Network-manager is established very late in boot process, so wrong ip-address with all that conflicts will stil happen. So mac-address by Network-manager is just a poor workaround, no final solution!

Don't know, where the information is collected from, armbianmonitor does not show the final mac address ...

rockpi-4a.armbianmonitor1.7z

Link to comment
Share on other sites

We used to mitigate random MAC problem (many drivers in the past were unable to read it from some unique hw id) with this script, which runs only once. Our primate network tool is Network manager with functional backing via ifupdown while it is difficult to have one system that is good for all. Then there is also a networkd type of networking which was recently added, but I agree we lack proper documentation for all this. I general this network mess should be cleaned, make a clear choice of which to use (build and run time) and make a proper documentation. Perhaps we have already open a Jira for that, if not, someone has to add it. Then someone, who we lack the most, has to find the time to do something about ...

But also I have to mention that generall policy about networking is / was: once board boots up with a working networking - which can be sometimes challenging due to the changing upstream kernel 1 2 3 4 5 ...  - our job is done. Optionally we try to secure its MAC doesn't go random. Nothing more than that. How you will set IP, VLAN, VPN, whatever ... its in users domain. We are not doing to cover in documentation since Armbian is Debian based and it all Debian/Ubuntu how-to should work. Yes, this policy can be improved with additional resources.

 

5 hours ago, tony013 said:

by the way: mac-address of Network-manager is established very late in boot process, so wrong ip-address with all that conflicts will stil happen. So mac-address by Network-manager is just a poor workaround, no final solution!


Isn't it only important that MAC is set before talking to the DHCP server. 

 

5 hours ago, tony013 said:

So - its not only for being impatient, the tool seems not to work as it should - or I'm stil to dumb to use it. The ping is just to proove, that I have internet access enabled.

 

The tool relies on 3rd party paste infrastructure. We had even more problems in the past, so we were thinking to move into our infrastructure - I think we even have it, but don't use. This would give us more control and I could answer you to this questions. Now I have no idea why its not working for you. I tried on my random armbian machine and it works for me. For example, you can check this testing report, which runs various of tests on the hardware and adds armbianmonitor for each board - check "report" column.
 

5 hours ago, tony013 said:

As a common user, you won't care which tool provides network support as long as the network works.


A choice for Network manager lies in simpler usage for its users. UX is far superior then ifupdown and its one tool that covers CLI and desktop at the same time. Surely its technically not the most bullet proof system, but we have been with almost since the start. Its pro points wins over its con. Ifupdown (which is mainly deprecated) should take over if IP settings are added. If not, then its a bug. If MAC is not taken, its bug again and could be tied to the network driver itself. (speaking generally - i don't know for this specific case)

 

16 hours ago, tony013 said:

@developers

 

<rant>

FYI. IMHO there are about 1/1000 of needed resources which listen to this forum and follow up on ideas that pops up :( Some ideas are important, some not, some simple, some difficult - projects for months if not years. And most of that kind of projects are close to impossible to start with the resources we have, without funding / serious full timers. All people that contribute are already busy (over the top), there are tasks - we have select as something that is realistic to finish - that waits for months to be addressed. Also it is hard to motivate newcomers to join and do this (sometimes very hard) work and mainly in exchange for eternal fame. They are not much interested even in selection of easy tasks. People just want to have professional support and professional software without giving anything for.

</rant>

Link to comment
Share on other sites

vor 13 Minuten schrieb Igor:

Then someone, who we lack the most, has to find the time to do something about ...

Well, I would be willing to write some docs, but ...

1. - I guess, I need some permission to do so

2. - I'm absolutely not qualified to talk about network or system internals

... but if that's ok, I could write about my experience

 

vor 15 Minuten schrieb Igor:

Isn't it only important that MAC is set before talking to the DHCP server. 

That's the point - I suspect (can't proove it, its only like a feeling), that DHCP server responds to armbians mac address before using "my" mac-address. When I try to access internet right after connecting with ssh to rockpi, I have no permission to do so.

Waiting a few seconds, the ssh-connection breaks.

At reconnect, ssh rants about suspicious address entry. I accept that warning by writing "yes" and ssh-connections is established second time. This time internet access works fine.

When I'm to lazy in starting ssh-connection, the above will not happen.

 

 

vor 22 Minuten schrieb Igor:

A choice for Network manager lies in simpler usage for its users.

Everything you know is easy - the rest is hard stuff

 

 

vor 23 Minuten schrieb Igor:

<rant>

I appreciate your rants, as they show the other side of the game ...

 

vor 24 Minuten schrieb Igor:

People just want to have professional support and professional software without giving anything for.

Well, that's not true for everybody.

I'm willing to learn and do the job on my own, but I've almost no glue about it. So I need a helping hand, some pushes into the right direction, whatever helps.

I don't expect others to solve my problem.

I don't know, what's a resonable way of living together. I'm just a user and I wasn't able to compile armbian on my own (following your documentation). I know, my questions are steeling your time - but what can I give back?

You can count my experience with rockpi in hours - not in years.

Link to comment
Share on other sites

6 hours ago, tony013 said:

I need some permission to do so


If you know around Github: 

https://github.com/armbian/documentation

https://github.com/armbian/documentation/tree/master/docs 

also via direct links on https://docs.armbian.com/

 

6 hours ago, tony013 said:

I'm absolutely not qualified to talk about network or system internals

... but if that's ok, I could write about my experience


If this is not a technical manual style that would fit into general docs, then this subforum is a proper place: https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/

 

6 hours ago, tony013 said:

That's the point - I suspect


Can't say anything without research ... but currently I barely found time to read a few forum topics this week ... it could be something new that we don't know about. I'll try to recreate what you are saying during next week if possible. Perhaps someone else will.

 

6 hours ago, tony013 said:

Everything you know is easy - the rest is hard stuff

 

Good one :thumbup:

 

6 hours ago, tony013 said:

Well, that's not true for everybody.


Ofc not.

 

6 hours ago, tony013 said:

I'm willing to learn and do the job on my own, but I've almost no glue about it.

 

6 hours ago, tony013 said:

I don't know, what's a resonable way of living together. I'm just a user and I wasn't able to compile armbian

 

Anything that helps - fixing trouble / growing the project. We have many open tickets, we would like to solve, but we can't follow. Not everyone are technical difficult. But also other non technical skills are helpful - running projects, coordinating / editing internal content production, help moderatring forum, ...

And ofc any area from Jira / "Help wanted" section. Some tasks are trivial - just to break the ice. Improving - how to join UX - is again something important to be done.

 

Even I would like to help, I am also busy like hell those days. Whenever someone shows interest to help on our common troubles, we help how we can. Sometimes the problem people find aligns with our priorities, sometimes it doesn't and we can't do much right spot on. Best effort.

 

6 hours ago, tony013 said:

You can count my experience with rockpi in hours - not in years.


You have, seems like a lots of general Linux userland experiences and that is what can help us. If trouble is hw related, we have some know-how, "just" time is needed ...

Link to comment
Share on other sites

vor 14 Stunden schrieb Igor:

And ofc any area from Jira / "Help wanted" section. Some tasks are trivial - just to break the ice.

Ok, I created my first pull-request with a network section in troubleshooting guide.

 

With Jira - I don't know, seems not to work. I read, that communication about a topic should happen in Jira, so I created an account. But probably you have to grant me some permissions to enable participating ...

 

So how should I start with Jira topics? For example, AR-735 is a topic, that sounds interesting. I use that pwm overlay on armbian as well as patches at LE ...

What needs to be done?

 

by the way: we're quite off topic already. Where's the right place for this kind of questions?

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines