Mount vs. add network share

Hi,

Easy question… What is the difference between adding a new source (http://kodi.wiki/view/Adding_video_sources) and mounting a network share (noeit.com) except for the first being a GUI approach instead of the terminal?

If different. Why would I use one or the other?

Thanks!

I have not seen any diff.
other than adding scraper DB
gui will prompt to config what DB to use then ask if you want to scrap

Am I wrong in this? I tied it and that’s what my system did

Regards
Sam

Well basically they use different implementations of samba. Generally there should not be any major diffenences other than:

  1. I you do fstab based mounts the files/folders on the samba server are also reachable on the command line and not only within Kodi
  2. Some people report better performance with fstab based mount

Like fzinken said… I noticed instant file play when mounting vs. 3+ second wait for play when using SMB share from GUI.

Mounting a network share via fstab is more complicated to set up but will always perform better than using the built in network browser in Kodi. This is because the kernel based nfs/smb clients are a lot more efficient and do a lot more read ahead buffering than the user mode clients built into Kodi.

On this subject, my NAS share requires a username and password for the Pi to access the files.

I set it up using the gui.

How secure is my saved password on the Pi? Is it held in an encrypted file?

Cheers, Scott.

It’s not store securely. If you used “Add network location” the password will be in plain text in passwords.xml.

If you just put the username and password in the smb:// URL it will be in plain text in sources.xml.

Thank you, I’ll use fstab and a password file in the encrypted home directory instead then.

Cheers, Scott

You have an encrypted home directory, fancy :slight_smile:
Just the Kodi files are also in your home directory so that would be the same :wink:

But to be honest the encrypted home directory doesn’t really have two much of a value as Kodi would have access to the uncrypted files anyhow.

Sorry, I probably don’t then, I’d assumed it could be encrypted, as per other Linux systems.

What you have to ask yourself is who/what you’re trying to protect yourself against if you encrypt your home directory.

You would typically do that on a laptop that might get stolen or lost to protect your data, however I’m not sure that it makes a lot of sense on an OSMC install.

The biggest threat would probably be password stealing by a malicious addon and regardless of whether that home directory was encrypted Kodi and thus the addon would have permission to read the file.

A more secure way would be to use a password file in the fstab mount option and have that password file be readable/writeable only by root, then at least Kodi (or anything running as the osmc user) doesn’t have access to it.

In retrospect, a better idea: I may move all my media to a non-passworded NAS for all networked media devices to easily access, and keep the passworded NAS for our personal stuff.

My worry was someone remotely getting into the pi and reading the NAS password. but I have changed the default password of the Pi to help fight against that. I host a website from home, so have a domain name pointed to my house, Just trying to make sure I’m not leaving myself open… plugging the holes…

Thanks, Scott

Kodi Addons are definitely a potential security hole. They have full file system access as the user that Kodi runs as.

Does sound like a good idea to separate your media files and personal documents.

Well if it is samba that would not work as non-password samba is not supported anymore.
But configuring different user/password for different shares makes sense.

Anyhow watchout on the add-ons you are installing as a foot in your LAN.

Thanks for the tip on add-ons,I’ll be sure to play it safe.

I think I’ll definitely split media away from personal… I also use Plex Server that allows me to remotely play music when away from home via the web app, this may also be a possible hole to fill.

Cheers, Scott