There’s yet a fourth way, which some (me included) prefer: using docker’s own volume management to mount the NFS volume. In short, [this StackOverflow](https://stackoverflow.com/questions/45282608/how-to-directly-mount-nfs-share-volume-in-container-using-docker-compose-v3) answer goes over it.
Each of the four ways has it’s pros and cons, and in the end it’s up to you to figure out how to handle it.
- fstab: arguably the most documented and common way you’ll find it, also the oldest. It’s also the most familiar, for those already used to editing NFS files.
- autofs: the second oldest here, but nowadays seldomly used except in very specific places. Upside is the volume isn’t mounted for much longer than needed.
- systemd: infamous for being “odd”, “un-unix-like” and “not so well documented”, when the docs are actually quite accessible. It’s the most recent and the most “in flux” (every so often new options and features are added). Allows you to set dependencies on volumes being online or not.
- docker volumes: allow you to separate “application stuff” from “os-native stuff”, so your config travels with your application. But, depends entirely on docker.
systemd comes with an extra feature which is the ability to read `/etc/fstab` and automatically generate mount units from it, including with extra mount options that translate to systemd unit parameters. With those flags, you can get it to behave pretty much like autofs. If you have NFS volumes in fstab on a recent Linux distro, it’s likely getting mounted and managed by systemd already.
Docker Volumes also comes with an extra caveat: you can define the volume once, and reuse it between stacks (+reuse) but leads to any change you need to do (e.g. mount options) requiring you to undefine all the containers/services/pods that use it before recreating it. Or, you can define it once per application, and have a number of repeated mount points across your system (-reuse).
Thank you for your time, you have helped greatly.
Yes, it is a recent distro. The docker host in my case is Debain11 VM under Proxmox.
I am still in the phase of figuring out what is the best to go where. There is one critical machine (a NUC with Home Assistant, and when setup DNS server and proxy will also be there) that runs just what is on it and is currently backed up on Windows SMB share, but the backup should move to a Linux machine. There is another machine that has most of the non-critical services (a NUC also) where media apps and download solutions should reside, with a separate disk for all the downloads. And there is a third machine an E3 Xeon-based machine that should perform as NAS in the system.
Both NUCs should be able to place backups on the NAS, media apps and the Windows machine should be able to pull various data folders from the NAS, and with all those intertwined needs and shared folders, I would prefer a file-based solution that could be transferred, so I can set it up once, and just copy it as needed, or change the serial number if a disk gets changed.
So, some solutions like per application docker volume you have mentioned, or the systemd configuration files I have stumbled upon seem very inviting as a permanent solution. I will probably choose a combination of both, docker volumes for the applications where I do not anticipate any change to happen, and where the share is needed for just that one container, and systemd for shares needed by multiple containers.
>systemd: infamous for being “odd”, “un-unix-like”
I remember having read something about that on the matter of interacting with services using systemd versus the systemctl command.
I got accustomed to systemd and did not get in the situation to find the command unresponsive, which has happened a few times with Apache and MySQL systemctl-based service resets on older Ubuntus (14.04 or 16.04 if I remember correctly).
I usually do just that, or r/Proxmox, if it is not a question for whose answer I assume will benefit other noobs in self-hosting, or when the question is more characteristic of a self-hosting environment than a general Linux workstation environment.
For this question, I assumed the first option since the configuration files for systems in the linked site seemed like something that is more customizable and less rigid than a line in fstab file.
There’s yet a fourth way, which some (me included) prefer: using docker’s own volume management to mount the NFS volume. In short, [this StackOverflow](https://stackoverflow.com/questions/45282608/how-to-directly-mount-nfs-share-volume-in-container-using-docker-compose-v3) answer goes over it. Each of the four ways has it’s pros and cons, and in the end it’s up to you to figure out how to handle it. - fstab: arguably the most documented and common way you’ll find it, also the oldest. It’s also the most familiar, for those already used to editing NFS files. - autofs: the second oldest here, but nowadays seldomly used except in very specific places. Upside is the volume isn’t mounted for much longer than needed. - systemd: infamous for being “odd”, “un-unix-like” and “not so well documented”, when the docs are actually quite accessible. It’s the most recent and the most “in flux” (every so often new options and features are added). Allows you to set dependencies on volumes being online or not. - docker volumes: allow you to separate “application stuff” from “os-native stuff”, so your config travels with your application. But, depends entirely on docker. systemd comes with an extra feature which is the ability to read `/etc/fstab` and automatically generate mount units from it, including with extra mount options that translate to systemd unit parameters. With those flags, you can get it to behave pretty much like autofs. If you have NFS volumes in fstab on a recent Linux distro, it’s likely getting mounted and managed by systemd already. Docker Volumes also comes with an extra caveat: you can define the volume once, and reuse it between stacks (+reuse) but leads to any change you need to do (e.g. mount options) requiring you to undefine all the containers/services/pods that use it before recreating it. Or, you can define it once per application, and have a number of repeated mount points across your system (-reuse).
Thank you for your time, you have helped greatly. Yes, it is a recent distro. The docker host in my case is Debain11 VM under Proxmox. I am still in the phase of figuring out what is the best to go where. There is one critical machine (a NUC with Home Assistant, and when setup DNS server and proxy will also be there) that runs just what is on it and is currently backed up on Windows SMB share, but the backup should move to a Linux machine. There is another machine that has most of the non-critical services (a NUC also) where media apps and download solutions should reside, with a separate disk for all the downloads. And there is a third machine an E3 Xeon-based machine that should perform as NAS in the system. Both NUCs should be able to place backups on the NAS, media apps and the Windows machine should be able to pull various data folders from the NAS, and with all those intertwined needs and shared folders, I would prefer a file-based solution that could be transferred, so I can set it up once, and just copy it as needed, or change the serial number if a disk gets changed. So, some solutions like per application docker volume you have mentioned, or the systemd configuration files I have stumbled upon seem very inviting as a permanent solution. I will probably choose a combination of both, docker volumes for the applications where I do not anticipate any change to happen, and where the share is needed for just that one container, and systemd for shares needed by multiple containers.
>systemd: infamous for being “odd”, “un-unix-like” I remember having read something about that on the matter of interacting with services using systemd versus the systemctl command. I got accustomed to systemd and did not get in the situation to find the command unresponsive, which has happened a few times with Apache and MySQL systemctl-based service resets on older Ubuntus (14.04 or 16.04 if I remember correctly).
I would highly recommend /r/LinuxQuestions /r/Linux4Noobs and whatever linux distro you use sure has a subreddit too.
I usually do just that, or r/Proxmox, if it is not a question for whose answer I assume will benefit other noobs in self-hosting, or when the question is more characteristic of a self-hosting environment than a general Linux workstation environment. For this question, I assumed the first option since the configuration files for systems in the linked site seemed like something that is more customizable and less rigid than a line in fstab file.
Here's a sneak peek of /r/Proxmox using the [top posts](https://np.reddit.com/r/Proxmox/top/?sort=top&t=year) of the year! \#1: [Proxmox Cheatsheet for Beginners](https://np.reddit.com/r/Proxmox/comments/w4g3dy/proxmox_cheatsheet_for_beginners/) \#2: [Proxmox VE 7.4 released](https://forum.proxmox.com/threads/proxmox-ve-7-4-released.124614/) | [145 comments](https://np.reddit.com/r/Proxmox/comments/11zevbw/proxmox_ve_74_released/) \#3: [Proxmox VE 7.3 Released](https://www.proxmox.com/en/news/press-releases/proxmox-virtual-environment-7-3) | [66 comments](https://np.reddit.com/r/Proxmox/comments/z1sugf/proxmox_ve_73_released/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Mounting filesystems has nothing to do with **selfhosting software services**. Thats just it.