Rclone mount frequently drops when using Plex

Help and Support
1

What is the problem you are having with rclone?

I have two rclone mounts that I use with Google Drive for Plex purposes. For the past few weeks I have been noticing problems when I refresh any one of my Plex libraries a) I temporarily lose connection to Plex b) I temporarily lose connection to my server c) one of the mounts drops. I have tried a variety of different mount commands but whichever I use results in it dropping. The problem has worsened and hence why I am here. Now, even deleting a film in Plex will result in the rclone mount dropping. It has gotten to the point where it is almost unusable. If all I do is access Plex to play an item then I have no problem, any maintenance is another story.

It could be said that this started around the time I changed some settings on my Mac. I was having issues with my 2012 Mac mini reaching its full potential now that we have gigabit speeds. Apple Discussions led me to making a manual adjustment to the network hardware settings: 1000baseT, full-duplex, energy-efficient ethernet, and standard (1500) MTU. But that could be coincidental.

I hope I have filled all necessary details correctly and I look forward to any assistance. Thanking you.

What is your rclone version (output from rclone version)

rclone v1.54.0

Which OS you are using and how many bits (eg Windows 7, 64 bit)

macOS Catalina 10.15.2, 64 bit

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

This is my current mount and one that I first noticed issues with:
rclone mount remote: ~/drive/ --allow-other --cache-db-purge --buffer-size 256M --dir-cache-time 72h --drive-chunk-size 32M --timeout 1h --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit off &

Before the above I would use the following but it became an issue with REMUXes:
rclone mount remote: ~/drive/ --allow-other --cache-db-purge --buffer-size 64M --dir-cache-time 72h --drive-chunk-size 16M --timeout 1h --vfs-cache-mode minimal --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit 1G &

I have also entertained the bog standard mount.
rclone mount remote: ~/drive/ &

All the above have had the same issue with dropping.

The rclone config contents with secrets removed.

This is the mount which drops frequently:

[remote]
type = drive
client_id = deleted
client_secret = deleted
scope = drive
token = {"access_token”:”deleted}

This mount never seems to be an issue.

[gdrive2]
type = drive
client_id = deleted
client_secret = deleted
scope = drive
root_folder_id = deleted
token = {"access_token”:”deleted”}

Both the above have the same api, they also use the same client_id and client_secret (maybe that is the issue?)

A log from the command with the -vv flag

I've uploaded log files for both when I have refreshed a library and deleted content:
Dropbox

2

hi,

--cache-db-purge does nothing based on your remote config

after reverting the settings; did the problems go away?

3

Thanks for the tip.

With regards Mac settings, I haven't reverted to original settings since my internet speeds were too slow as they were.

4

those log files are 16MB in size.

i suggest that you revert the network settings, reboot and test again.
after that, if the problem persists, then with a new set of debug logs, we can deep dive into them.

5

I have done just that but it has unmounted again. I was saving the log as verbose, is there another command you'd recommend?

7

This is where the mount disappears... would that be correct?

   2021/02/17 15:15:03 DEBUG : Google drive root '': Checking for changes on remote
    2021/02/17 15:16:03 DEBUG : Google drive root '': Checking for changes on remote
    2021/02/17 15:16:53 DEBUG : /Media/movies/.grab: >Getattr: errc=-2
    2021/02/17 15:16:53 DEBUG : Google drive root '': Destroy: 
    2021/02/17 15:16:53 DEBUG : Google drive root '': >Destroy: 
    2021/02/17 15:16:53 DEBUG : Not calling host.Unmount as mount already Destroyed
    2021/02/17 15:16:53 DEBUG : Unmounted successfully
    2021/02/17 15:16:53 DEBUG : rclone: Version "v1.54.0" finishing with parameters ["rclone" "mount" "remote:" "/Users/plex/drive/" "--log-file=mylogfilenew.txt" "--log-level" "DEBUG"]
8

yeah, i did go thru the logs and saw that, not sure what is the cause.

no worries,
now we know that those network changes are not the cause of the problem.
we have many experts and one should stop by soon and deep dive into the logs.

9

Look forward to it. Thanks.

10

This sounds very like the problem in this thread

Except in your case the networking is being very slow and that causes the OS to kill the mount.

Try adding --daemon-timeout 9m and see if that makes any difference.

11

Right you are, I shall see if that works. Thank you.

12

Well nothing has happened as yet, so it seems that this has resolved the issue. I am entirely grateful.

13

Let me know if it does get wrong - I'm not 100% sure that is the correct solution.

If it does work I'll change the default in the beta.

14

hi,

how did you determine that, something from in the logs?

15

You can see how long the various operations take in the logs. If they take longer than 2 minutes then you get this problem.

16

Could you also try --daemon-timeout 10m - that should work and if it does I'll make it the new default.

The current default is 15m but I think the maximum allowed is 10m so macfuse 4 must be setting it to lower.

17

I'll do that right now and let you know how I get on. The 9m has definitely improved things, I put my Plex server through the wringer yesterday and I encountered no drops with the mount whatsoever.

18

Yes 10m works too.

Really appreciate your assistance in getting this resolved so fast. Thank you and stay healthy.

19

Thank you for testing :slight_smile:

20

I've changed the default to --daemon-timeout 10m for macOS

I've merged this to master now which means it will be in the latest beta in 15-30 mins and released in v1.54.1

1 Like
21

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.