Mount NFS under Haiku

Help
21

THANKS Lrrr and leavengood. The code and the entries in /var/log/syslog leaded to the solution

/var/log> tail -n5 syslog
KERN: nfs4: Error not B_OK or empty stream!
KERN: nfs4: Decode Error!
KERN: Last message repeated 2 times.
KERN: nfs4: nfs4_mount()Error mounting filesystem: Invalid Argument

The arguments looked OK and as you use the exact same syntax I checked that on another NAS in the network. It works!
Shame on me! The mistake was that the NAS protocol on the old NAS was set to NFS2/NFS3 but NFS4 was disbaled. PEBKAC!

3 Likes
22

I think some of the blame lies with Haiku on this one. Thatā€™s a misleading error message. Ideally it would say ā€œProtocol not supportedā€ or ā€œServer not respondingā€ or something.

1 Like
23

Yes we should try to improve things like that. With that said NFS4 is a pretty advanced thing to use and is also fairly new in the code. Also Iā€™m not sure if detailed errors can really be returned in something generic like fs_mount_volume which can handle any kind of file system.

This is one big downside of C style error handling. I think we have similar issues when using the pkgman utility where ā€œGeneral system errorā€ is returned many times :confused:

Error handling has been discussed pretty recently on the haiku-development mailing list but I donā€™t know if we had a clear consensus. And changing it in a big way would probably require major API breakage.

3 Likes
24

I wasnā€™t trying to say that the function could return a string like that. There are probably other error codes that could have been chosen, like ECONNREFUSED, EPROTO, EPROTONOSUPPORT, etcā€¦

1 Like
25

Yeah that would be an improvement but my comment was more about ā€œI wish we could do betterā€ than an excuse for the status quo. Probably printing out ā€œplease check the syslog for more detailā€ would help too.

26

just to make it clear (Iā€™ve struggled too with this command)ā€¦

if your shared folder is /srv/nfs4/my_folder on your remote system, youā€™ll need to call the mount command this way:

mount -t nfs4 -p "192.168.1.253:/my_folder" /boot/home/Desktop/mount_point

and not: mount -t nfs4 -p ā€œ192.168.1.253:/srv/nfs4/my_folderā€ etcā€¦ like you could do for scp for example (without the full path on the server, only the subfolder)

4 Likes
27

Iā€™m coming to this hella late, but I got my system to connect to my NAS with this syntax:

mount -t nfs4 -p 192.168.4.100:/shares/Fritz /boot/home/Desktop/Assets

My issue was the use of quotes. Iā€™m not sure why that would have been an issue, but it works like a charm.

F

3 Likes
28

Anybody knows if/how using credentials is possible (username and password)?

29

I got the mount command working, but then only see an empty folder (but with the share icon, so it is recognised as a network share in Tracker). Seems to be a security misconfig but works without problems on Linux (gotta check the config there closely now):

KERN: nfs4: NFS Error: Operation not supported
KERN: nfs4: NFS Error: Operation not allowed
30

I have been experiencing issues mounting nfs from haiku as well.
I was getting a permission denied.
I have traced the problem to my Virtual Machine configuration.
I am running Haiku inside VirtualBox. Its network configuration defaults to NAT.
As such, the NFS connection went through this NAT, and came from an unpriviledged port, such that the NFS server would reply permission denied.
Configuring the network adapter to Bridged mode solved the issue.

1 Like
31

thanks, forgot to post my update here, was also a permission issue in the end.
Quite pesky with TrueNAS and NFS permissions, but I found the right (and simple) POSIX config mix to make it work.
Additionally, there was a setting ā€œinherit permissionsā€ which I thought was more hierarchical, but it applied to new files as well. So even when permissions were corrected, I couldnā€™t create new files or foldersā€¦:wink:

32

I own a NAS Synology but I never got the ā€œmountā€ command working fine, so instead I have used ā€œmount_nfsā€.

Below are the various tests which indicates thereā€™s no permission issue, however not sure to understand what is wrong with ā€œmountā€ or if an option/argument is not correctly used?

2025-04-28_23-42
2025-04-28_23-42884Ɨ165 18 KB

1 Like
33

Are you all connecting using credentials? If so how?

Or did you have to create a public/password-less share on you NAS?

34

AFAIK, NFS is not using credentials but instead IP adresses and uid/guid.
On the NAS, the list of authorized ips is available in the /etc/exports file

1 Like
35

If you are using the regular mount command then you must specify the filesystem type with -t nfs4. So, in your case it should be something like mount -t nfs4 -p 192.168.1.79:/volume1/documents /boot/home/NAS/documents

1 Like
36

Indeed with that option itā€™s now working fine!
Thanks :slight_smile:

1 Like
37

One comment on ā€œmountā€ with -t nfs4 : the performance is quite better than ā€œmount_nfsā€ which is a good news (it might be due to the nfs version used).

3 Likes
38

I wish the Haiku automounter would support network shares natively, this is so Linux like:(

39

patches welcome ducks

but seriously, we should be able to auto-discover and auto-mount shares with dns-sd, just has to be done eventually. :smiley:

1 Like
40

Iā€™d love to see this Haiku style with a directory acting as the share mount having a special file type and the ā€œsharedā€ attribute as defined in BVolume and server/protocol/directory/opts as attributes.

Then the auto mounter could transparently pick this up and mount the volume using this informationā€¦:nerd_face:

The user would just have to create a new share from e.g. Tracker New templates and fill in the blanks, and be done.

1 Like