using nfs in emby 3.0.8000

[ozooha 0]

How does one go about using the nfs share path in the new version of the emby server?

 

Say for the folder part I have

 

 /media/TVShows

 

then its optional shared network folder section be what?

 

nfs://IP Address of the server/media/TVShows ?????

 

FYI:

my nfs mount part of the /etc/fstab/ is

 

192.168.1.12:/   /mnt   nfs    auto  0  0

 

 

and under /mnt the directory for the TVShows is

 

/mnt/media/TVShows

 

Kindly help.

Thanks.

OZooHA

[Luke 42077]

Whatever would be used by the other devices on your network. so for example, if you have another device that is a PC, browse to the network share and look at the path being used there.

[ozooha 0]

Whatever would be used by the other devices on your network. so for example, if you have another device that is a PC, browse to the network share and look at the path being used there.

Thanks Luke for taking a few minutes of your time.

So if its a nfs mount like in my first post what should it look like?

This below

nfs://IP Address of the server/media/TVShows 

or something else

To emphasize do i need to specify the protocol i.e. nfs or smb?

[Luke 42077]

It depends on the devices you are accessing from, but I would use the protocol as a starting point then adjust if it doesn't work.

[ozooha 0]

It depends on the devices you are accessing from, but I would use the protocol as a starting point then adjust if it doesn't work.

I use

\\IP Adress\<folder path>

and it assumes it as SMB which I don't want as I have my Linux system with nfs.

Can you be specific instead of being general please.

Thanks.

[Luke 42077]

I apologize about being vague, but the reason I'm doing so is because the answer is "it depends", based on the devices that you're using.

 

you could try nfs://... , if \\ is having an issue. Let us know how it goes. Thanks.

[puithove 209]

Most of the client apps are not going to support NFS natively (Kodi might be the only one I can think of).  Whereas quite a few of them do support SMB.

 

If you're running clients on Linux, and you want to use NFS for the file sharing, I'd recommend just mounting the NFS shares on those clients so that the paths match up with how the server is accessing them.  If you do that, then the client will first try the same path that the server uses, and if it's unable to access it that way, it'll next attempt to use the "shared network" path you define.

 

So for example:

Server uses local path:  /media/TVShows  (this can be an NFS mount also)

On client mount that NFS share also to /media/TVShows

 

Then you can also share the same path out with SMB for any other clients that understand that.  Just put \\<server>\path\to\share in the "shared network" path for the library.

[gstuartj 40]

@@puithove That would work, but it's not possible on all embedded devices, and it kills the convenience and flexibility of a URL.

 

In my use-case the only clients that are accessing my network share directly are Kodi clients, so just defining an NFS source works great. It would be nice to be able to define shares for both protocols, though.

Edited October 18, 2016 by gstuartj

[mastrmind11 722]

So does this upgrade kill the way existing nfs path substitution works?  If I upgrade, do I have to set paths up again and rescan my libraries?  Does it effect my HTTP streaming setup?

Edited October 18, 2016 by mastrmind11

[Luke 42077]

You do not have to set your libraries up all over again.

[ozooha 0]

I apologize about being vague, but the reason I'm doing so is because the answer is "it depends", based on the devices that you're using.

 

you could try nfs://... , if \\ is having an issue. Let us know how it goes. Thanks.

So i did try them both ways (meaning nfs:\\ and nfs://) and I got the same response as in this thread:

https://emby.media/community/index.php?/topic/40338-nfs-support-for-new-shared-network-folder-setup/

i.e.

"There was an error adding the media path. Please ensure the path is valid and the Emby Server process has access to that location."

[ozooha 0]

So does this upgrade kill the way existing nfs path substitution works?  If I upgrade, do I have to set paths up again and rescan my libraries?  Does it effect my HTTP streaming setup?

The current version honours the old "path substittuion" so keep that in tact till they resolve this issue in the new versions.

[ozooha 0]

Most of the client apps are not going to support NFS natively (Kodi might be the only one I can think of).  Whereas quite a few of them do support SMB.

 

If you're running clients on Linux, and you want to use NFS for the file sharing, I'd recommend just mounting the NFS shares on those clients so that the paths match up with how the server is accessing them.  If you do that, then the client will first try the same path that the server uses, and if it's unable to access it that way, it'll next attempt to use the "shared network" path you define.

 

So for example:

Server uses local path:  /media/TVShows  (this can be an NFS mount also)

On client mount that NFS share also to /media/TVShows

 

Then you can also share the same path out with SMB for any other clients that understand that.  Just put \\<server>\path\to\share in the "shared network" path for the library.

I have it set up this way on a client and it works great.

[ozooha 0]

@@puithove That would work, but it's not possible on all embedded devices, and it kills the convenience and flexibility of a URL.

 

In my use-case the only clients that are accessing my network share directly are Kodi clients, so just defining an NFS source works great. It would be nice to be able to define shares for both protocols, though.

yes I would also rather prefer this as well.