NFS mount for Apps

[neurokrish]

@robi sure, I created a file, let's say, x.conf in /etc/systemd/system/docker.service.d as mentioned in the link posted above. The contents of that file are,

media-movies.mount is just my systemd unit for the NFS mount. I have rebooted my server a few times after this change and my files are all accessible in apps as desired!

[robi]

@neurokrish Sounds like it also needs the contents of what that references.

[neurokrish]

@robi perhaps there is some other way. I will try to dig a little deeper to see if there is any other solution!

[A Former User]

Unrelated but I did a double take reading NFS as NFT. This forum has not been tainted yet.

[robi]

@atridad it has been now.

[nebulon]

I took a quick look at this and the proposed solution to have the dependencies properly setup are not working due to a dependency loop.

unbound requires docker
volumemount requires unbound but has to be started before docker

not quite sure how to resolve that, have to investigate further or does anyone have an idea or are there any best practices with systemd dependencies and docker container startup?

[robi]

@nebulon I don't see a loop.

You have docker already, and unbound and volume mounts can be done with volumes or binds mounts via docker cli..

https://docs.docker.com/storage/volumes/

Escape values from outer CSV parser

If your volume driver accepts a comma-separated list as an option, you must escape the value from the outer CSV parser. To escape a volume-opt, surround it with double quotes (") and surround the entire mount parameter with single quotes (').

For example, the local driver accepts mount options as a comma-separated list in the o parameter. This example shows the correct way to escape the list.

$ docker service create \
    --mount 'type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=local,volume-opt=type=nfs,volume-opt=device=<nfs-server>:<nfs-path>,"volume-opt=o=addr=<nfs-address>,vers=4,soft,timeo=180,bg,tcp,rw"'
    --name myservice \
    <IMAGE>

[nebulon]

@robi my explanation lacked some detail. Let me try to explain with my first morning coffee, maybe helps me sort it as well

On cloudron we have those volumes, which are essentially mounts on the host system. Those are managed by systemd and can be configured via the dashboard. Then such a volume or mounted folder essentially, can be mounted into an app. (note Cloudron volume !~ docker volume and same for mounts, the terminology is not exactly the same)

Now if the system starts up, the docker daemon will startup up the containers, at which point the host mounted folders have to be available, otherwise docker will mount empty folders into the apps. The unbound service is required for reliable volume host resolving https://git.cloudron.io/cloudron/box/-/commit/a56766ab0e7f13cbc678fee80d3cea2a86d12c71 so it has to be up an running prior to Cloudron volume mounts. All clear so far I think.

Now docker needs to be started before unbound, at least according to the unit file adjusted with https://git.cloudron.io/cloudron/box/-/commit/4d55783ed865922b155c71e8b17533fdd5d850ec this leads to the mentioned loop and systemd breaks the loop during startup by postponing host mounts in this case, according to the systemd startup logs.

Two possible solutions here. Some smart way with systemd to solve such situations, which I don't know yet, or double check why unbound requires to be run after docker. Maybe @girish can shed some light here, I can't remember why that was required back then.

[robi]

@nebulon in this case, what is unbound actually doing? resolving anything?

If so, one solution is to use 'names' that don't need resolving or add it to the local resolver.

Get more explicit.

[girish]

@robi said in NFS mount for Apps:

If so, one solution is to use 'names' that don't need resolving or add it to the local resolver.

that's right, a workaround is use the IP address directly instead of names.

[nebulon]

This is fixed for the next release. We found a way to remove docker as a startup dependency of unbound and thus can mount volumes prior to docker and resolve the remote volume's DNS.

Essentially the trick was to tell unbound to listen to future interfaces (in this case the local interface for the docker network, where the apps are running in) https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html?highlight=ip-freebind#term-ip-freebind-yes-or-no

[girish]

For more info, look for IP_FREEBIND in https://www.man7.org/linux/man-pages/man7/ip.7.html . Didn't know such a thing existed.

[robi]

Amazing, and makes all the difference!