Kodi Community Forum

I know that using NFS Manager to set up NFS shares on OS X has been discussed in other threads and tutorials and the wiki. But I thought it best to start a forum thread specifically about setting up NFS, rather than about why SMB doesn't work on OS X, etc.

My issues thus far:

1) how do you tell if the NFS server is running?*
2) how do you start & stop the server?

* edit: found answers to those questions already. Both can be done using nfsd commands in the terminal. Type "man nfsd" in terminal for details. But I do still wonder, doesn't NFS Manager allow you to do these things in its GUI? If so, how? If not, why?

3) What about permissions/login? That's the big issue.

I currently have security set to "system standard only" and access permissions to "allow access from any network and computer" as recommended. And that allows connection from Kodi just fine with the zeroconfig browser (tho curiously not via the NFS option, why?). However, I'm not asked for any user name or password. Are these shares open to the world (WAN)?? If so that's obviously not ok.

Tips:
I had to set up port forwarding on my router to get this to work. That's something not covered by the wiki or in the forum posts I've seen, or at least not obviously. It's covered in the NFS Manager manual, which states these ports need to be open and forwarded to the OS X server.

• port 111 and the port range 600–1023 for RPC communication.
• port 2049 for access to the NFS server

I have detailed in the nfs wiki how authentication with nfs works. If you read it you get an idea why there is no username/password. For why the nfs server is not found by the nfs option? Because Apple NFS server is not providing the needed udp bits as it seems.

(2015-08-07, 16:02)Memphiz Wrote: [ -> ]I have detailed in the nfs wiki how authentication with nfs works.

Sorry, still don't understand this. I am running Kodi right now on an iPad running iOS 8.4 and current Kodi version. (This is mainly a test; ultimately I'll run Kodi on a Pivos DS under Linux, if there is an unofficial build produced, otherwise maybe TOFU or whatever, yuck, another reason sticking with Frodo for now… But I digress…) From what you said, I don't believe that (Kodi on iOS/iPad) is running as root, correct? And I didn't configure the N option on the server. (and I double checked the com.apple.nfs.plist file* to confirm). Yet I can connect to everything.

And still not clear about exposure to WAN. Assuming wanting to be able to connect to home server while away, i.e. via the WAN is desirable, how could this be achieved with NFS securely? Any client running as root can connect?? Clearly that's not good.

* side note: currently running el capitan. can users even edit a file in /System/LaunchDaemons/ with SIP enabled?

It seems that your last post is mostly unrelated to your first post. And i don't even know where to start to comment tbh. If i say configure the N option that you should configure the N option. The fact that it works for you is something which i would call by accident.

Sry - have no time left - your post is way to crowded for me to get any usefull organisation into it.

(2015-08-10, 12:41)Memphiz Wrote: [ -> ]It seems that your last post is mostly unrelated to your first post. And i don't even know where to start to comment tbh. If i say configure the N option that you should configure the N option. The fact that it works for you is something which i would call by accident.

Sry - have no time left - your post is way to crowded for me to get any usefull organisation into it.

Thanks for the reply. sorry for the verbosity. But the last post is not unrelated to the first post, which raised 3 questions. The last post deals only with the 3rd. And it's a simple question I still have no clarity about:

Quote:Are these shares open to the world (WAN)??

Quote:still not clear about exposure to WAN. Assuming wanting to be able to connect to home server while away, i.e. via the WAN is desirable, how could this be achieved with NFS securely? Any client running as root can connect??

if they are exposed to wan depends on your router/isp configuration. Safely accessing nfs from wan should be done via encrypted vpn normally.

(2015-08-20, 08:48)Memphiz Wrote: [ -> ]if they are exposed to wan depends on your router/isp configuration. Safely accessing nfs from wan should be done via encrypted vpn normally.

OK, thank you. Yes, they would be exposed in that case, as I would want it to be for access away. Setting up encrypted VPN is something I could look into, but it seems complicated (and costly?) and would likely interfere with other WAN network services access. Which makes, it seems to me, NFS not a good solution for me. Which again makes me wish for functioning SMB. But that's OT

(2015-08-08, 11:04)ctawn Wrote: [ -> ]

(2015-08-07, 16:02)Memphiz Wrote: [ -> ]I have detailed in the nfs wiki how authentication with nfs works.

* side note: currently running el capitan. can users even edit a file in /System/LaunchDaemons/ with SIP enabled?

Regarding this part of your post (as the wiki hasn't been updated to deal with NFS and Mac OS X 10.11 El Capitan):

No, users, not even with sudo, su -, or logged in as root, can edit LaunchDaemon .plist files without a little bit of work.

1) Restart/boot the Mac, hold down Command-R to enter the Recovery Partition
2) Once booted in the Recovery Partition, click on Utilities in the menu bar and click on Terminal
3) Enter this: "/usr/bin/csrutil disable" to disable SIP. see the following for an explanation of what this is if you care to: http://www.macworld.com/article/2948140/...tions.html
4) Quit Terminal, restart the mac normally
5) Then do whichever method you prefer to edit /System/Library/LaunchDaemons/com.apple.nfsd.plist and add "<string>-N</string>" to the appropriate spot, according to the wiki. Save the file.
6) Restart the Mac, hold down Command-R again and repeat the above, only this time enter "/usr/bin/csrutil enable" to get SIP going again.
7) Again, quit terminal, restart the Mac, and Bob's your uncle: nfsd will now start the way the way we want it to according to the wiki.

I assume the wiki will be edited at some point to include this information, maybe in a week or so once El Capitan is officially released.

Add it yourself please - it's a Wiki so that users can contribute on its own - thx for the howto

Wiki updated at http://kodi.wiki/view/NFS#Fresh_Installs...El_Capitan
There are two days to go until El Capitan is officially released, so it seemed like as good a time as any to take your advice and do the edits myself.

Goal: Run TOFU (flavor of KODI 14 or 15) on Pivos DS Media Play and connect by NFS to server running on Mac OS X El Capitan (10.11.1) .

Problem: XBMC Frodo 12.3 (currently functional connecting to OS X El Capitan via AFP) will not connect to NFS server running on OS X. Here is a log showing the attempts.

Considerations: XBMC Kodi 15.1 running on iOS 8.4 on iPhone 6 does appear to connect to the same server via NFS. If I can expect the same of a variant of Kodi 14 or 15, then I may personally not have an issue. But I'm hesitant to make the jump given that all is working at the moment with current setup.

Is it a known issue that Frodo clients can't connect to NFS?

I have carefully configured NFS on the Mac, including configuring the N flag (involving disabling SIP as described above.)

From the Kodi video library sharing pages: "If you use smb:// paths, you may want to use static IP addresses rather than NetBIOS names, as not all your devices may be able to resolve the latter."

I assume this applies to NFS shares as well.
It appears from your logs that you are attempting to connect to MacPro.local. Enter the IP address instead and try that.

(2015-10-17, 00:40)killdabob Wrote: [ -> ]Enter the IP address instead and try that.

Thank you! That seemed to work. At least as far as opening the share directly from the sources list. (I could swear that somewhere I read that you should use the computer.local variant with NFS, but ok, apparently not…)


Now I seem to have a problem with path substitution, which I have defined as:


This log seems to show that AFP is still being used:


Then, even more oddly, if the original path started with: "afp://ctawn:[email protected]/" – as is the case with more recently added media, getting info on that media appears to be the cause of a crash. (See the end of the log, from this line):


Now, I'm not sure this is the cause of the crash. Previously I was also having a crash with getting info on recently added media. But I tracked it down to an add-on (tvtracker). Once I disabled that, while AFP was still active, there hadn't been more crashes. I will revert my advancedsettings.xml file to the original and test that again. [Edit: tested, and unfortunately same crash with original substitution. Meaning all the more reason I'm eager to get "up-to-date" ASAP.]

The original path substitution was defined as this:


In the media info windows, the path was never shown with the IP. always with "MacPro.local". What might that mean?

Honestly, this is beyond my knowledge of Kodi. I followed http://kodi.wiki/view/MySQL to get my systems up and running. Maybe you can try to pick and choose things from that wiki to get your own thing going. I don't know what your goals are, but following that wiki accomplished all of mine: 1) Share the library from my media server/main HTPC to all other systems, 2) Keep watched status the same across all systems. It works perfectly for that.

Thanks for the response, KB. Of course, I wouldn't expect that you personally could address this issue, but I do hope someone can chime in. My needs are actually simple, maybe simpler than yours. I have no need to share a library or sync anything. I just want to have a stable system with one server and one box that is capable of adapting to the changing protocol restrictions over time. The path substitution is necessary to retain my library and change from AFP (apple file protocol) to NFS, given that AFP support has been cut and SMB support for Macs running current OS X versions does not work.