Support other (browseable) types of volumes with the volume browse feature

[oramirite]

Is your feature request related to a problem? Please describe.
The volume browser feature implemented from #1380 and #2051 works great when volumes exist at the default volume mount point. However, I am using a 3rd party volume drives for ZFS that allows the mount point for volumes to exist outside of the Docker data directory. These volumes DO show up correctly in Portainer, with the custom zfs label and everything. Even the "mount point" column even shows the correct mount point. This means the fix developed for #956 is working great too. So far so good!

However, when I click the browse button I get an error:
Failure: open /var/lib/docker/volumes/data/services/wiki/db/_data: no such file or directory
The actual mount point for this dataset on the host is "/data/services/wiki/db", which again, is correctly shown in the mount point column. I would expect to see:
Failure: open /data/services/wiki/db: no such file or directory

So the volume browse feature must be constructing the path manually form the volume name. I haven't actually looked at the source to confirm this yet, but all signs point to this being the case.

Describe the solution you'd like
Use the "mount point" of a volume as the source path for browsing the volume. This would also require users to make sure these paths are mounted and browsable in the container itself.

Describe alternatives you've considered
I can't really think of a fringe case where using this property wouldn't be better than constructing it manually. This shouldn't even break browsing to existing volumes that are in the default volume path, as those mount points should stay the same as they were.

Additional context
As an aside... there is a way to create named volumes that use the 'bind' property, essentially re-mapping a named volume to a filesystem location outside of the /var/lib/docker folder. Even with this use case, Docker was re-mapping my bound folder into the volumes directory. So the volume browsing feature still worked with that setup even though the paths were technically different. With this ZFS plugin, the paths are fully outside of the Docker directory now, producing this issue.

[ncresswell]

The volume browser only supports volumes created by the Docker “local” driver, no other drivers are (or will be) supported.

Likely we will put a detection to hide the browse button for any volume that is not supported.

[oramirite]

Hiding the button is a good idea, and thanks for the reply.

Although I could make some guesses - do you mind elaborating on the rationale for this? I imagine it's because of far too many edge cases to support, but the nature of the docker volume plugin system seems to imply that if a volume even HAS a mount point, then it is available on the host to browse like a local filesystem. We could filter out volumes without a mount point and hide the browse button from those instead.

I do understand why this would be a pain, but I just want to voice that this is unfortunate for this particular use-case. I was hoping I'd have a fully GUI-based file and volume management system integrated with ZFS by getting this set up. Now, unfortunately, I have to choose between volume browsing in the GUI and integration with ZFS datasets.

I do realize this isn't Portainer's problem, but I wanted to bring up what I thought was a pretty compelling use-case if more capabilities were added to volume browsing. Thanks again for the reply and consideration either way :)

I think I might work around this by mapping the host filesystem bind mount to the dataset I'm storing these ZFS volumes in. Then they will still be browse-able from the host browse feature.

[ncresswell]

Because to be able to browse, we need to first have bind mounted the hosts file system into Portainer; it why we have you bind mount /var/lib/docker/volumes to Portainer and our agent. To support other vols means either we must bind mount the / volume (dangerous) or have known, and bind mounted prior, a base volume for other drivers (eg /glusterfs/).

[oramirite]

Yeah, my expectation here was that the user would have to know ahead of time to do this.

Since you already instruct users to bind mount the host filesystem to support host browsing, I figured taking the same step for volumes existing outside of the /var/lib/docker/volumes could be considered similar.

If this step isn't taken, an error would be shown in the GUI at it currently does - except it would show the mount path that it's expecting, instead of the incorrect one it currently does.

[oramirite]

So to address your questions, I would propose:

• Use the mount point of a volume to enable browsing, instead of a generated path.
• If said mount point doesn't exist within the container, then don't show the browse button.

This should catch any volume drivers that don't actually create readable filesystems, even if they have a listed mount point. Basically any volume whose mount point exists in Portainer could be enabled for browsing.

[Giraffaman]

has it been considered to look for a Docker config file like /etc/docker/daemon.json? I am using that file to point docker's data_root to a separate disk mounted in /mnt/docker, so all my docker data, including volumes, is held there.

I have stacks with volumes using the local driver and am able to see the volume browse button in Portainer with the correct mount point being listed, but I get the above-mentioned "no such file or directory" error when clicking the volume browse button.

Is there some config file in Portainer where one could specify where to look for volumes instead of /var/lib/docker?