So I did some more playing around over the week-end. I started with a clean minimized install of Ubuntu Server and went on to install the necessary components and setting up fstab for the NFS share and bindfs option as well. 

It mounted properly and creating files or directory showed that it worked as expected.
I deployed a couple containers and mapped them to the bindfs directory and it deployed and ran as it should. However after a restart of the host, the bind wouldn’t mount anymore. It threw an error saying the directories weren’t empty.
I found that weird.

So I tried the other avenue (which so far still works) of mounting the NFS share in fstab and then in the compose files, modifying the volumes to the mount point location.
The only downside, is that I have to manually create the directories before deploying a container.
Deploying directly fails for directory creation permissions, however, rerunning compose up creates the directories the second time around. Even though I did not adjust anything.

I will try this out during the week if I can. 

The Docker daemon runs as root user or another user like "docker". This user needs to have permissions to access and manage the data root directory or any bind-mounted directories. But, it does not need to match the uid/gid of the user owning the NFS share.

Your mount of the volume (NFS client) will receive access based on what permissions it has been configured with on the server side.

If the NFS share is mounted with the right user the uid/gid and permissions, your Docker containers and the daemon will be able to access it as expected.

So for instance:

sudo mount -t nfs -o rw,uid=1234,gid=1234 nfs-server:/share /mnt/nfs

Then you mount the storage as a bind mount in your container:

docker run -v /mnt/nfs/specific-dir:/app/data my-container

Hopefully this helps 😀  

Really appreciate the two suggestions. 🙂 

For the first part: Yes, both systems are Linux based.
I’ll check for the root_squash setting. I wasn’t aware of this. 

Permission wise, both mount point and share on each systems were owned by the same uid and gid. Also for some reason, it seemed to check for the name of the user rather than the uid, because once I set on the NAS root as the owner of the share, docker seemed to be happier. But I reverted back as I did not wanted root owning the share.

I had try to find the daemon to give it the proper uid, but did not realize it could be done by modifying docker.service. Still learning Docker, I used to run everything directly on dedicated VMs.

However, I like your second suggestion better as it’s way easier indeed, and it will do what I wanted, which is to have the data on the NAS and not on the VMs directly.

I’ll reset the Docker VM to start clean and will just map the share and bind mount it to containers. 
Going that route, does the docker daemon still need to have the same uid as the one owning the share?

So, for example:

version: "3.8"

services:
  app:
    image: nginx:latest
    container_name: container-I-want-on-nfs-storage
    ports:
      - "8080:80"
    volumes:
      - /mnt/nfs_share:/usr/share/nginx/html:rw
    restart: always

The bind mount will make sure the data for your container is stored on NFS while the data-root for docker itself remains the default. This way you can protect your data that you want for those specific containers and not change Docker's data root.

gid=1234.
Run the following commands on the NFS server:

sudo chown -R 1234:1234 /MyNFS/MountPoint/docker
sudo chmod -R 775 /MyNFS/MountPoint/docker

Also, make sure your share is mounted with the right options for Docker. Edit your /etc/fstab or mount command to use the following:

nfs defaults,rw,sync 0 0

Make sure your Docker daemon runs with the same user uid=1234. You can do this by modifying your docker.service file to include the directive:

user=1234

The last error that you posted there looks like there is conflicting docker configurations. You will want to use either systemd configuration file or the daemon.json file but not both. If you are using systemd configuration, make sure no data-root directive is in your daemon.json file. If you are using the daemon.json file, remove the --data-root flag from your systemd service file if that makes sense.

Once you have made your changes, try to restart the docker service:

sudo systemctl daemon-reload
sudo systemctl restart docker