There is of course an XKCD for this
Every bug fixed introduces an potential backwards incompatibility
There is an example we can explore in Install
# config on host at ~/.config/rclone/rclone.conf
# data on host at ~/data
# make sure the config is ok by listing the remotes
docker run --rm \
--volume ~/.config/rclone:/config/rclone \
--volume ~/data:/data:shared \
--user $(id -u):$(id -g) \
rclone/rclone \
listremotes
# perform mount inside Docker container, expose result to host
mkdir -p ~/data/mount
docker run --rm \
--volume ~/.config/rclone:/config/rclone \
--volume ~/data:/data:shared \
--user $(id -u):$(id -g) \
--volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro \
--device /dev/fuse --cap-add SYS_ADMIN --security-opt apparmor:unconfined \
rclone/rclone \
mount dropbox:Photos /data/mount &
ls ~/data/mount
This works fine with v1.57 however if we change it slightly to this then it fails with v1.57 but works with v1.56
# perform mount inside Docker container, expose result to host
mkdir -p ~/data
docker run --rm \
--volume ~/.config/rclone:/config/rclone \
--volume ~/data:/data:shared \
--user $(id -u):$(id -g) \
--volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro \
--device /dev/fuse --cap-add SYS_ADMIN --security-opt apparmor:unconfined \
rclone/rclone \
mount dropbox:Photos /data &
ls ~/data
This is is exactly equivalent to the OPs case and seems quite likely people might run into it.
Perhaps we should tighten the /proc/mounts check to refuse only to mount on a fuse filing system, or even maybe just on an rclone fuse filing system?
Rclone mounts look like this
s3:rclone /mnt/tmp fuse.rclone rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
so perhaps looking for a fuse.rclone
might be enough?
I think the error message is perfectly clear - it says the problem and it says which flag to use, so I'm not too worried about that.