Propogating rclone mounts to Docker containers without transport endpoint going stale

Howto Guides
1

I'm writing this guide because after over a year of trying to figure out how to get around this issue, I finally found a solution (and it's just one line). Jump to the end of this thread if you just want the code without the context.

The issue:

If you've ever binded an rclone mount as a volume for a Docker container then you must be familiar with this problem. If an rclone mount that is binded as a volume to a Docker container is ever restarted, the mount (transport endpoint) becomes stale and the Docker container will no longer be able to see the mount. To get around this you would have to restart the container every time the rclone mount is restarted.

The solution:

You could just make sure the dependent containers only start after the rclone mount is connected (and in fact this is what I did for a very long time using Docker health checks), but this is very slow and creates other complications.

A better solution I recently discovered is to change the Docker volume's bind propagation method to rshared. This flag recursively shares any child mount points at the bind volume's path with the container. For example, let's say your rclone mount is at the path /mnt/data on the host. Your bind volume configuration in a compose.yaml will then be:

volumes:
  - /mnt:/mnt:rshared

Notice that I did not bind /mnt/data you MUST bind the parent directory, otherwise it will not propagate correctly. With that, rclone mounts will propagate correctly even after a mount is restarted.

I've never seen this solution posted anywhere which is why I'm sharing, hopefully this saves someone from the frustration I went through :slightly_smiling_face:

2

Do you think we should put this on the docs?

I think there has been discussion of rshared either here or on GitHub before.

3

Hey, sorry about the late reply. I definitely think adding this to the docs would be helpful. I've been sharing this tip with a bunch of people over the last few days and they've all been happy to get it working the way I described.

One thing I'll say is that if you add this to the docs, maybe use a different example to the one I used. Mapping /mnt:/mnt would be bad practice and a security issue. Someone less tech savvy might not realize that.

4

@ncw I'm not sure if you still plan to add this to the docs but I found some more info that might be useful if you do.

If you look back at my original post, I mentioned that you need to mount the parent directory of the target folder. This can actually be avoided. I found that the rslave bind propagation has the same benefits of rshared but without needing to pass the entire parent directory (probably because rslave propagates mounts in one direction unlike rshared which is bidirectional).

This is obviously better because we have more granularity with restricting file access to the containers. Like I mentioned in my original post, binding the parent directory could be a security issue.

Here's a more full example using the rslave method instead rshared.

services:
  rclone:
    image: rclone/rclone:latest
    command: mount xxx:/ /data --allow-other
    volumes:
      - /mnt/data:/data:rshared

  some_service_that_needs_the_rclone_mount:
    image: some_image
    volumes:
      - /mnt/data:/data:rslave
5

your example still uses rshared ??

6

Yes, but only on the rclone container. That's intended.

7

ok, good.
you are welcome to edit the documents yourself, click the pencil icon at
https://github.com/rclone/rclone/blob/master/docs/content/install.md

have you seen these pages?
https://rclone.org/docker/
https://rclone.org/commands/rclone_serve_docker/