james-portainer

The reason this happens is because when a stack is created with compose via the CLI, there is no back reference to the compose file that created the resulting stack. As such, Portainer has no way of knowing how the stack was created and for safety we flag these as limited stacks. If the stack is deployed through Portainer, we save the compose file and reference it in our database to that stack.

The directory names within the Portainer data volume are given numerical identifiers because stack names can change, and because we let you manage multiple environments from one Portainer instance we also need to allow for the same stack name to exist on more than one environment. The directories weren't initially intended for direct access outside of Portainer.

At present, Portainer is built on the one server multiple agents model where you have one environment that is your "management" interface and runs Portainer Server, and the others use the Agent to interface with the Server. You can only log into the environment running the Portainer Server container, not the Agents. We don't currently support multi-tenancy of the Portainer Server.

In production setups we generally recommend a separate environment purely for management, where workloads don't run, that you run the Portainer Server on, and all workload environments use Agents. This way if one of your workload environments goes down, you can still manage the others in the meantime.

If you've mounted your share to /media/nfsshare1 on your host OS and you can write to it from within Linux, you should just be able to bind mount /media/nfsshare1 to a directory within your container in the same way you do a non-NFS local path - under the Volumes tab in Advanced container settings when creating a container, or in your stack yaml. As far as Docker will be concerned, it is a local path - since the mounting is done at the OS level through fstab, Docker has no idea what it actually is underneath.

If on the other hand you want to create a NFS volume in Portainer, you wouldn't do the mounting via fstab and instead do it all in the Create volume page (or in your stack yaml).

You shouldn't need to build the image - the image already exists on Docker Hub. What you want to do is create a container (or stack) that uses the existing image on Docker Hub. Here's a slightly modified version of the stack file from the NPM documentation that you can deploy in Portainer (the only change I've made is to turn the relative path bind mounts into named volumes):

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'

    volumes:
      - data:/data
      - letsencrypt:/etc/letsencrypt

volumes:
  data:
  letsencrypt:

In Portainer, go to Stacks, click Add stack, give the stack a name, then paste this into the Web editor and deploy.

Building an image is generally reserved for when you are either creating an image from scratch or are extending an existing image with your own modifications. Simply deploying a container from an image that someone else has created doesn't require any image building.