Help me understand the difference between Ubuntu and Debian

[Bladefin]

@EliteAlienhas kindly went over Proxmox and using LXC, if I'm correct I see that this isn't actually supported by Jellyfin. 

You then have Ubuntu and Debian that is officially supported by Jellyfin.

What is the main difference between those two considering I will be a Linux newbie, Someone I was talking to the other day said if I'm not use to Linux then it might be good to use Ubuntu or Debian Desktop version, but would I also be correct in saying Jellyfin doesn't officially the desktop version? and would the desktop version be just as stable as bare metal. 

At the moment I'm using a Windows laptop but I am waiting on the Beelink N150 to be in stock, should be in a couple of weeks. 

My usage will only be for within my home network no remote watching and my movies are stored on a Synology NAS.

Thanks

[TheDreadPirate]

"Linux", technically, only refers to the kernel. A kernel is the core piece of code that provides an interface between the hardware and software that you run. This is true of all operating systems.

One thing more unique to the Linux kernel is its modularity and customizability. And that enables may different ways to create a Linux based operating system.

"Distributions" are Ubuntu, Debian, Arch, Fedora, etc. They provide ecosystems of software that run on top of the Linux kernel. Each distribution makes different choices of what software they bundle by default, how it is configured by default, and how "cutting edge" they want their distribution to be. Regarding that latter point, Arch would be an example of a "cutting edge" distro. Running the latest version of all packages and kernels, which can result in software breaking but you gain the latest features and performance. This is compared to a distro like Debian, which, by default, prefers stability. Meaning that there is much more testing done on software packages before they are pushed out to users. This provides stability and consistency that allows developers to not have to constantly modify their software to adapt to a changing environment.

Jellyfin does not care whether you run the desktop version or server version. The primary difference between desktop and server versions of a distro are whether they include a GUI by default. Server variants do not have a desktop UI out of the box. You CAN install them after the fact, though. Other than that, there are no meaningful differences between desktop and server variants and Jellyfin server can be run on either.

[Bladefin]

"Linux", technically, only refers to the kernel.  A kernel is the core piece of code that provides an interface between the hardware and software that you run.  This is true of all operating systems.

One thing more unique to the Linux kernel is its modularity and customizability.  And that enables may different ways to create a Linux based operating system.

"Distributions" are Ubuntu, Debian, Arch, Fedora, etc.  They provide ecosystems of software that run on top of the Linux kernel.  Each distribution makes different choices of what software they bundle by default, how it is configured by default, and how "cutting edge" they want their distribution to be.  Regarding that latter point, Arch would be an example of a "cutting edge" distro.  Running the latest version of all packages and kernels, which can result in software breaking but you gain the latest features and performance.  This is compared to a distro like Debian, which, by default, prefers stability.  Meaning that there is much more testing done on software packages before they are pushed out to users.  This provides stability and consistency that allows developers to not have to constantly modify their software to adapt to a changing environment.

Jellyfin does not care whether you run the desktop version or server version.  The primary difference between desktop and server versions of a distro are whether they include a GUI by default.  Server variants do not have a desktop UI out of the box.  You CAN install them after the fact, though.  Other than that, there are no meaningful differences between desktop and server variants and Jellyfin server can be run on either.

Thank you, So the only difference then  between the server and desktop is the server uses less resources ie memory and hard drive space,than the desktop version.

The way you install Jellyfin is the same on the server or desktop or is it a bit different?

[EliteAlien]

Thank you, So the only difference then  between the server and desktop is the server uses less resources ie memory and hard drive space,than the desktop version.

The way you install Jellyfin is the same on the server or desktop or is it a bit different?

Since I was "@" here. As the TheDreadPirate stated but a little extra to it.

Ubuntu Server is headless. Which means it has no GUI and you will install everything through a TTY or in other words a terminal. Meaning you install everything through typing it out.

Ubuntu Desktop Edition's have a GUI (GUI meaning a graphical user interface. Basically the desktop environment. Like if on Windows you have a background, menu system, and just a graphical space to work inside of).

Debian is what Ubuntu is based off of and in most cases things can be interchanged. However, there are some Debian packaged ".deb" and repositories (Where you get your software) that can't be interchanged between the two. Though with a desktop or server addition as long as it's the same release you can interchange Ubuntu Server and Ubuntu Desktop or Debian Server and Debian Desktop editions PPA's, Debian Packages, and the likes. For example, Ubuntu "Noble" release you wouldn't use Ubuntu "Jammy" packages.

Proxmox is Debian based and the LXC scripts used use a Debian Server image in the LXC container, but with the script it sets it up for you. Which is why I was saying if it was me starting over from scratch I would probably go that route. Not because Ubuntu or anything was exactly difficult, but that it's lazier I guess, lol. You run a script and go let it do it's thing and you can backup with Proxmox without additional software. While if you do Ubuntu, Debian, or any Debian based distro's. Well you will have to flash it to a USB drive and install it like you would Proxmox. However, if you want snapshots you will need either select filesystem types like BTRFS for its specific backups or need to install additional software to use it's "Snapshot" system. Which works, but if the OS hosting Jellyfin breaks you have to have a Live USB in this case to go into and then potentially "Chroot" and install that same software needed into the Live USB and restore the working OS. It's a few extra steps where as Proxmox would virtualize the system running Jellyfin and you can access it via a web browser to restore the system. Which makes it sort of the lazier method as I was saying before, lol. Not that these systems really break, but Jellyfin updates can sometimes have problems so backing up is a must. (Jellyfin 10.11.X builds have been a nightmare for me so I've reverted backups on my VM multiple times. 10.11.9 update from 10.11.8 deleted my databases for libraries and stuff. 10.11.8 to 10.11.10 worked fine.)

Returning back to no "Server" builds you are correct that they usually use less resources. Since they don't install everything under the sun and you sort of install what you need and only what you need. Not all server distro's are like "Arch" as mentioned before, but they tend to be ran in a TTY like if you were setting up Arch Linux. Though Ubuntu, Debian, and a few other Server distro's even ones not based on "Debian" do have installer GUI's to click through and install the OS. So you will not be installing it like you would Arch having to MKFS (maker your filesystem with a "ext4", "btrsf", and so on file system you specify and run commands for making and partitioning your drives. Nor by hand making sure your boot partition is made and you have a boot loader like Grub, Systemd-Boot, and so on. To have a OS selection when the system posts.)

As for installing. Yes they will all install basically the same. The best way is technically through a terminal. On a Debian based distro it would be "sudo apt install jellyfin jellyfin-server jellyfin-web" unless they name the packages differently. If you install this bare-metal on the mini-pc, as I was mentioning before about the CPU being your GPU. Don't expect it to be the best transcoder in the world, but you may need to also install the "intel-media" or even the older drivers for the decoding for Intel HD graphics. Mesa by default has a lot of stuff for the graphics side of things, but not all the codec stuff. "Intel-media" also has two packages the "free" and "non-free". The free is missing a few things for decoding and encoding media and in some cases the "non-free" is the way to go. Basically "free" is the opensource and "non-free" is the proprietary drivers.

Hopefully I broke it down pretty well for you. If you have further questions I am sure TheDreadPirate or myself can further elaborate on it.

[Bladefin]

Thank you, So the only difference then  between the server and desktop is the server uses less resources ie memory and hard drive space,than the desktop version.

The way you install Jellyfin is the same on the server or desktop or is it a bit different?

Since I was "@" here. As the TheDreadPirate stated but a little extra to it.

Ubuntu Server is headless. Which means it has no GUI and you will install everything through a TTY or in other words a terminal. Meaning you install everything through typing it out.

Ubuntu Desktop Edition's have a GUI (GUI meaning a graphical user interface. Basically the desktop environment. Like if on Windows you have a background, menu system, and just a graphical space to work inside of).

Debian is what Ubuntu is based off of and in most cases things can be interchanged. However, there are some Debian packaged ".deb" and repositories (Where you get your software) that can't be interchanged between the two. Though with a desktop or server addition as long as it's the same release you can interchange Ubuntu Server and Ubuntu Desktop or Debian Server and Debian Desktop editions PPA's, Debian Packages, and the likes. For example, Ubuntu "Noble" release you wouldn't use Ubuntu "Jammy" packages.

Proxmox is Debian based and the LXC scripts used use a Debian Server image in the LXC container, but with the script it sets it up for you. Which is why I was saying if it was me starting over from scratch I would probably go that route. Not because Ubuntu or anything was exactly difficult, but that it's lazier I guess, lol. You run a script and go let it do it's thing and you can backup with Proxmox without additional software. While if you do Ubuntu, Debian, or any Debian based distro's. Well you will have to flash it to a USB drive and install it like you would Proxmox. However, if you want snapshots you will need either select filesystem types like BTRFS for its specific backups or need to install additional software to use it's "Snapshot" system. Which works, but if the OS hosting Jellyfin breaks you have to have a Live USB in this case to go into and then potentially "Chroot" and install that same software needed into the Live USB and restore the working OS. It's a few extra steps where as Proxmox would virtualize the system running Jellyfin and you can access it via a web browser to restore the system. Which makes it sort of the lazier method as I was saying before, lol. Not that these systems really break, but Jellyfin updates can sometimes have problems so backing up is a must. (Jellyfin 10.11.X builds have been a nightmare for me so I've reverted backups on my VM multiple times. 10.11.9 update from 10.11.8 deleted my databases for libraries and stuff. 10.11.8 to 10.11.10 worked fine.)

Returning back to no "Server" builds you are correct that they usually use less resources. Since they don't install everything under the sun and you sort of install what you need and only what you need. Not all server distro's are like "Arch" as mentioned before, but they tend to be ran in a TTY like if you were setting up Arch Linux. Though Ubuntu, Debian, and a few other Server distro's even ones not based on "Debian" do have installer GUI's to click through and install the OS. So you will not be installing it like you would Arch having to MKFS (maker your filesystem with a "ext4", "btrsf", and so on file system you specify and run commands for making and partitioning your drives. Nor by hand making sure your boot partition is made and you have a boot loader like Grub, Systemd-Boot, and so on. To have a OS selection when the system posts.)

As for installing. Yes they will all install basically the same. The best way is technically through a terminal. On a Debian based distro it would be "sudo apt install jellyfin jellyfin-server jellyfin-web" unless they name the packages differently. If you install this bare-metal on the mini-pc, as I was mentioning before about the CPU being your GPU. Don't expect it to be the best transcoder in the world, but you may need to also install the "intel-media" or even the older drivers for the decoding for Intel HD graphics. Mesa by default has a lot of stuff for the graphics side of things, but not all the codec stuff. "Intel-media" also has two packages the "free" and "non-free". The free is missing a few things for decoding and encoding media and in some cases the "non-free" is the way to go. Basically "free" is the opensource and "non-free" is the proprietary drivers.

Hopefully I broke it down pretty well for you. If you have further questions I am sure TheDreadPirate or myself can further elaborate on it.

Again thanks, I get it now you broke it down well enough for me to understand 🙂 

I have watched those videos you posted in the other post, I understand about the scripts now, with those jellyfin scripts they are managed by the community and not Jellyfin supported, and my understanding they are always a release behind.

I can only see the difficult part will be learning how to mount my Synology NAS to Proxmox and adding it to the Jellyfin LXC.

[EliteAlien]

I have watched those videos you posted in the other post, I understand about the scripts now, with those jellyfin scripts they are managed by the community and not Jellyfin supported, and my understanding they are always a release behind.

The scripts get you setup, but since it's an LXC container it would be running a Debian image so technically if you wanted to update Jellyfin inside it. Well you could use the console inside of Proxmox and/or use SSH inside the LXC container. Then run an "sudo apt update && sudo apt upgrade". Which could update the packages. If not or you want to do it via Debian packages, then you could always pull a .deb file directly from the Jellyfin website that is made for Debian. Since Debian is supported with a deb packages, both in stable and unstable builds. These come in three files "jellyfin.deb", "jellyfin-server.deb", and "jellyfin-web.deb". So in theory, if you did a ssh into it and then "wget link-to-deb-file" then ran "sudo dpkg -i jellyfin.deb jellyfin-server.deb jellyfin-web.deb" it would then upgrade the packages. Though if you do this be it a bare-metal, LXC Container, or VM. It would be wise to have backed up before-hand. That way if an update broke something you can roll back. Even more so you want a backup if testing a 12.0 unstable build.

To not just give you commands and you not know what they are.

sudo (super user do. Basically telling the computer to use what Windows would call administrator access. In this case it's telling Linux to use root user privileges) (apt is what Debian based distros use as the package manager. So anything with "apt" in it will be calling the package manager where your distro gets the software and software updates. Different distributions have different package managers. Arch uses "pacman", Fedora/Red Hat uses "dnf", and so on. There are a handful of these.).

As for "dpkg" it just is a command for using the package manager with Debian packages. It's literally short for "Debian Package". Arch you don't have this but you can "sudo pacman -U package-name". Fedora/Red Hat you have RPM's which are similar to deb packages "sudo rpm -i name.rpm" to install them from a terminal. Other distros also have similar things as well.

Basically deb, rpm, and so on are kind of like a .exe file in a way, but distro specific and not fully packaged with everything like a executable file would have. Because sometimes they pull dependencies from your distro package manager to fill in the gaps. You can install these packages in a GUI too like an exe file, but if on a server build and you don't install a Window Manager / Compositor or Desktop Environment you need the commands. (Window managers are the things that tell the OS how to draw the windows on the screen and sort of how it should be placed. Compositor is the term used when using Wayland and it's basically the same thing but it can do Vsync and other compositing methods on the windows. Desktop Environments tend to be coined when you have a full package of a Window Manager / Compositor with a GUI on top to decorate the Windows and the likes.)

That probably seems like a lot to know, but once you get to using Linux and/or a distro of your choice it kind of falls into place. The terms, the commands, and the likes you get use to it. It's similar to if you started using Windows today never doing it before. Where you would need to learn all the terms, how to interact with the menus, and so forth. You can use a lot of distros without using any commands too. Which is kind of like Windows and not using the Power Shell. Yet, Linux doesn't always have a GUI for everything so you might end up using the commands once in a while on Linux verse say Windows. It heavily depends on the distro and if it has a GUI for the package manager and other tools. Anyway, it's not to difficult to pick up if your willing to and it might be daunting at first, but I would say that's the case for a lot of things when you first start learning.

[Bladefin]

I have watched those videos you posted in the other post, I understand about the scripts now, with those jellyfin scripts they are managed by the community and not Jellyfin supported, and my understanding they are always a release behind.

The scripts get you setup, but since it's an LXC container it would be running a Debian image so technically if you wanted to update Jellyfin inside it. Well you could use the console inside of Proxmox and/or use SSH inside the LXC container. Then run an "sudo apt update && sudo apt upgrade". Which could update the packages. If not or you want to do it via Debian packages, then you could always pull a .deb file directly from the Jellyfin website that is made for Debian. Since Debian is supported with a deb packages, both in stable and unstable builds. These come in three files "jellyfin.deb", "jellyfin-server.deb", and "jellyfin-web.deb". So in theory, if you did a ssh into it and then "wget link-to-deb-file" then ran "sudo dpkg -i jellyfin.deb jellyfin-server.deb jellyfin-web.deb" it would then upgrade the packages. Though if you do this be it a bare-metal, LXC Container, or VM. It would be wise to have backed up before-hand. That way if an update broke something you can roll back. Even more so you want a backup if testing a 12.0 unstable build.

To not just give you commands and you not know what they are.

sudo (super user do. Basically telling the computer to use what Windows would call administrator access. In this case it's telling Linux to use root user privileges) (apt is what Debian based distros use as the package manager. So anything with "apt" in it will be calling the package manager where your distro gets the software and software updates. Different distributions have different package managers. Arch uses "pacman", Fedora/Red Hat uses "dnf", and so on. There are a handful of these.).

As for "dpkg" it just is a command for using the package manager with Debian packages. It's literally short for "Debian Package". Arch you don't have this but you can "sudo pacman -U package-name". Fedora/Red Hat you have RPM's which are similar to deb packages "sudo rpm -i name.rpm" to install them from a terminal. Other distros also have similar things as well.

Basically deb, rpm, and so on are kind of like a .exe file in a way, but distro specific and not fully packaged with everything like a executable file would have. Because sometimes they pull dependencies from your distro package manager to fill in the gaps. You can install these packages in a GUI too like an exe file, but if on a server build and you don't install a Window Manager / Compositor or Desktop Environment you need the commands. (Window managers are the things that tell the OS how to draw the windows on the screen and sort of how it should be placed. Compositor is the term used when using Wayland and it's basically the same thing but it can do Vsync and other compositing methods on the windows. Desktop Environments tend to be coined when you have a full package of a Window Manager / Compositor with a GUI on top to decorate the Windows and the likes.)

That probably seems like a lot to know, but once you get to using Linux and/or a distro of your choice it kind of falls into place. The terms, the commands, and the likes you get use to it. It's similar to if you started using Windows today never doing it before. Where you would need to learn all the terms, how to interact with the menus, and so forth. You can use a lot of distros without using any commands too. Which is kind of like Windows and not using the Power Shell. Yet, Linux doesn't always have a GUI for everything so you might end up using the commands once in a while on Linux verse say Windows. It heavily depends on the distro and if it has a GUI for the package manager and other tools. Anyway, it's not to difficult to pick up if your willing to and it might be daunting at first, but I would say that's the case for a lot of things when you first start learning.

That's great thanks for the information of what those commands means, I feel much more confident about using Proxmox over Windows now,like you said it's just learning something new, I think using the scripts to start off with will be better and then when I get more confident in using it I will attempt to use without scripts.

I'm sure the mini computer will be fine for my use as I don't have any plans on using it for anything else. I do have a feeling I will be needing your assistance for when it comes to getting my Synology media folder added to the container, I've been reading so many people having issues with privileged and unprivileged, it looks a bit complicated when I have been reading what you have to do, I haven't yet seen a video that makes it simple to understand from a beginners point of view.

[EliteAlien]

That's great thanks for the information of what those commands means, I feel much more confident about using Proxmox over Windows now,like you said it's just learning something new, I think using the scripts to start off with will be better and then when I get more confident in using it I will attempt to use without scripts.

I'm sure the mini computer will be fine for my use as I don't have any plans on using it for anything else. I do have a feeling I will be needing your assistance for when it comes to getting my Synology media folder added to the container, I've been reading so many people having issues with privileged and unprivileged, it looks a bit complicated when I have been reading what you have to do, I haven't yet seen a video that makes it simple to understand from a beginners point of view.

Either Proxmox, Ubuntu, Debian, any distro really should be pretty easy to get into if going into it not expecting it to be "Windows". As it will be different, but similar in some ways, specially if using a GUI. Though homelab stuff like this it's usually better to use a server like distro. The Proxmox route will let you learn a bit about virtualization. Because once you go down the homelab route you sometimes end up hosting way more things over time. Home automation like HomeAssistant and many other things. It's a hobby but also ends up saving you money as you cut subscription costs and what not.

Does it use Samba shares out of the gate? I imagine it does since you connect to it in Windows right. Something like "\\ip-here\share-name" right? (The Linux way of typing it is smb://ip-here/share-name" in a file-manager) Linux unless you have a few ways to deal with shares. Some distros out of the box just show the shares in the GUI under "Network" on a file manager. It uses the "avahi" packages that runs in the background checking for Samba and NFS shares. Then uses "GVFS" to mount the share to your user. Without a GUI you can make it mount each boot in your fstab file using the "cifs-utils" packages, so each boot up it just has it. Though what is great about Proxmox is it has Samba and NFS built in. In the web interface you can even mount shares from your browser window. Then once you make this you can even passthrough a mount to the LXC Container or Virtual Machine by adding a "Hard Drive" to it in the "Hardware" tab. (https://www.youtube.com/watch?v=BqZipmXuPlc&theme=dark Quickly found that and skimmed it. Though it shows you a brief look at adding one via Proxmox. With the drop down menu. Along with other stuff I was talking about here.)

Proxmox makes it lazy mode for sure though, lol. Because once you've given an LXC or Standard VM access you just need to go into the console or ssh into it and mount it via the fstab file which is located in every Linux distro in "/etc/fstab". I've never really seen a distro move this so it's always there. You can then just "sudo nano /etc/fstab". ("nano" being a text editior that you use in a terminal. It's one of the better and easier ones to use and tends to be installed on most distros out of the box. If not "sudo apt install nano" since we're talking about Debian based distros.) Then inside this file is just the layout for how every hard-drive, SSD, or optical like media is mounted at boot of the OS. So if you wanted a HDD to mount at "/mnt/MYHDD" you could tell it to go there in this file.

[Bladefin]

That's great thanks for the information of what those commands means, I feel much more confident about using Proxmox over Windows now,like you said it's just learning something new, I think using the scripts to start off with will be better and then when I get more confident in using it I will attempt to use without scripts.

I'm sure the mini computer will be fine for my use as I don't have any plans on using it for anything else. I do have a feeling I will be needing your assistance for when it comes to getting my Synology media folder added to the container, I've been reading so many people having issues with privileged and unprivileged, it looks a bit complicated when I have been reading what you have to do, I haven't yet seen a video that makes it simple to understand from a beginners point of view.

Either Proxmox, Ubuntu, Debian, any distro really should be pretty easy to get into if going into it not expecting it to be "Windows". As it will be different, but similar in some ways, specially if using a GUI. Though homelab stuff like this it's usually better to use a server like distro. The Proxmox route will let you learn a bit about virtualization. Because once you go down the homelab route you sometimes end up hosting way more things over time. Home automation like HomeAssistant and many other things. It's a hobby but also ends up saving you money as you cut subscription costs and what not.

Does it use Samba shares out of the gate? I imagine it does since you connect to it in Windows right. Something like "\\ip-here\share-name" right? (The Linux way of typing it is smb/ip-here/share-name" in a file-manager) Linux unless you have a few ways to deal with shares. Some distros out of the box just show the shares in the GUI under "Network" on a file manager. It uses the "avahi" packages that runs in the background checking for Samba and NFS shares. Then uses "GVFS" to mount the share to your user. Without a GUI you can make it mount each boot in your fstab file using the "cifs-utils" packages, so each boot up it just has it. Though what is great about Proxmox is it has Samba and NFS built in. In the web interface you can even mount shares from your browser window. Then once you make this you can even passthrough a mount to the LXC Container or Virtual Machine by adding a "Hard Drive" to it in the "Hardware" tab. (https://www.youtube.com/watch?v=BqZipmXuPlc&theme=dark Quickly found that and skimmed it. Though it shows you a brief look at adding one via Proxmox. With the drop down menu. Along with other stuff I was talking about here.)

Proxmox makes it lazy mode for sure though, lol. Because once you've given an LXC or Standard VM access you just need to go into the console or ssh into it and mount it via the fstab file which is located in every Linux distro in "/etc/fstab". I've never really seen a distro move this so it's always there. You can then just "sudo nano /etc/fstab". ("nano" being a text editior that you use in a terminal. It's one of the better and easier ones to use and tends to be installed on most distros out of the box. If not "sudo apt install nano" since we're talking about Debian based distros.) Then inside this file is just the layout for how every hard-drive, SSD, or optical like media is mounted at boot of the OS. So if you wanted a HDD to mount at "/mnt/MYHDD" you could tell it to go there in this file.

On my Windows machine it seems simple it's SMB, and I just mount the media folder through windows credentials by entering the name of the folder and the password.

It seems SMB is better for Windows and NFS is better Linux.

Will watch that video properly but I have a feeling that I'm going to have to really do my research on a video tutorial for mounting a media folder only. I don't want to be mounting the whole nas.

Thanks

[EliteAlien]

It seems SMB is better for Windows and NFS is better Linux.

Furthest from the truth. Samba works great on Linux. I use it all the time. In fact I think NFS is lesser in some cases. NFS does not have the same security as Samba does out of the box. If you start NFS in most default setups it will attach itself to your whole network so anyone with your subnet can connect to it just by using the IP's 192.168.1.1/24 for example. Also it doesn't always have any encryption or authentication methods on default setups. You then have to set the IP's you choose to allow if you don't want that to happen. Though the thing is if you don't static them or someone else your local ip. Which in theory you can spoof that and/or your user id so that NFS thinks your the user at that IP. There is ways of hardening NFS more, but out of the gate it's not Samba. So when you go and add the extra security layers it slows down as it adds the additional overhead. So speeds of Samba and NFS are virtually the same at that point. You can remove some of the overhead of Samba by removing some of the security features in its config file. Though once you do that well it kind of defeats the point.

From using both I've seen not much of a major difference myself. One is slightly better with small files and one is slightly better with larger files. Though real world usage you wouldn't notice this much. I think it comes down to a few things with NFS vs Samba. One how your OS sets up the Samba and NFS configuration out of the gate. (Because tweaking them regardless of the two is usually a good idea depending on your use case.) Then how willing you are to tinker with it. Because you can make Samba or NFS more secure or less secure with their configurations. You can even limit connections based on versions of the software, refusing older versions connections and stuff. Though the more you add, the more overhead and thinking it has to do before it makes a connection.

Edit: If you do use NFS I would suggest making sure you understand your configuration. Specially if you ever expose a network for outside access. Because there is a "Root Squashing" issue with NFS. Where remote users can gain full root level access to all your files. Just by having a local IP. Since as I was saying, out of the gate, not all configurations are equal. Your NAS might be a bit more hardened, but I would still suggest looking at your configuration and understanding it. Because even inside the network, you can still give read and write access to all users inside that network by using a local IP and having a similar user id.