Kodi Community Forum

Full Version: sh: 1: nmblookup: not found
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
While trying to find out why scanning for nfs shares kodi returns nothing
(directly specifying the full nfs path works), I found this:

start kodi from the command line
add a new source
search nfs file systems

now the shell gets

sh: 1: nmblookup: not found

while kodi.log says
2019-09-03 19:34:25.329 T:139969887992512   ERROR: GetDirectory - Error getting nfs://
2019-09-03 19:34:25.329 T:139969887992512   ERROR: CGUIDialogFileBrowser::GetDirectory(nfs://) failed

So - why should nmblookup get involved when looking for an NFS share?

Ubuntu 19.04 kernel 5.2.11
Kodi 18.4 git: 20190831-3ade758
Check the timeline, it's used for samba, which the same dialogue also triggers.
(2019-09-03, 20:47)fritsch Wrote: [ -> ]Check the timeline, it's used for samba, which the same dialogue also triggers.

I am not talking about a dialogue but the Menu for searching a new source (translated back from German)

- 1.86 TB disk
- Records
- Home directory
- Network filesystem (NFS)
- root filesystem
- video playlists
- windows share (SMB)
- zeroconf browser
- add a network share

I am selecting Network filesystem (NFS) which should show NFS shares. Some months (or years) ago it still did. Now, instead the error message about missing nmblookup appears.

IMHO, listing NFS shares should not involve SMB at all.

However I can add the NFS share manually with "add a network share"

So now I installed nmblookup - but still do not get NFS shares listed. From shell, the command
showmount -e s5
where s5 is in the local networks shows all nfs mounts on s5.

Are there any other requirements for getting nfs shares listed in kodi?
What are you using for the machine which provides the shares.

In case of UnRaid 6.7.x there's an open issue for not able to browse NFS shares anymore: https://forums.unraid.net/bug-reports/st...-nfs-r551/

I have the same problem currently. And I initially thought it's a libnfs issue. Hence I reported it here first: https://github.com/sahlberg/libnfs/issues/294

As my NAS doesn't respond to rpcinfo -b 100005 2 we found out it's an issue at UnRaid and the bugreport confirms that somehow.

So in the end, it's not a Kodi issue, AFAICT.

And yes, showmount -e <NAS-IP> works fine and I can still mount my shares by the OS. But I'm neither able to browse them via Kodi, nor am I able to browse them via the filemanager the OS (Ubuntu in that case) provides.
do you use NFSv4? because libfns doesn't support browsing for nfs4 shares iirc
(2019-09-04, 09:56)DaVu Wrote: [ -> ]I have the same problem currently. And I initially thought it's a libnfs issue. Hence I reported it here first: https://github.com/sahlberg/libnfs/issues/294

As my NAS doesn't respond to rpcinfo -b 100005 2 we found out it's an issue at UnRaid and the bugreport confirms that somehow.

So in the end, it's not a Kodi issue, AFAICT.

And yes, showmount -e <NAS-IP> works fine and I can still mount my shares by the OS. But I'm neither able to browse them via Kodi, nor am I able to browse them via the filemanager the OS (Ubuntu in that case) provides.

This put me on the right track. Here is the solution: https://sourceforge.net/p/rpcbind/discus...0805bc7dd/

So rpcbind on the NFS server would have to be compiled with a special option, or kodi people can persuade them to make this a runtime option instead of a compile time option.
See also https://sourceforge.net/p/libtirpc/mailm.../36377522/ for why this was not done as runtime option
in short: too much work and
Quote:I've had customers complaining about this random listening port for years and I only know of one app (rpcinfo) that used this feature so I'm fairly sure its not going to be missed...

Otherwise I guess kodi should try to find another way to find shares, maybe find all servers and use showmount on each of them.
Thanks @wolfgang61 

I'll report that to the UnRaid guys as well

@wsnipex 

nope, no NFSv4 on my side as Unraid doesn't support that by default