Rclone cmount silently stops

Help and Support
21

Hello @ncw and thank you for your continued assistance!

Indeed, grepping for Readdir did yield some additional results:

unique: 3, opcode: READDIR (28), nodeid: 58, insize: 80, pid: 2983
readdir[8] from 0
2021/02/13 15:39:07 DEBUG : /Fotomateriaal/unknown: Readdir: ofst=0, fh=0x8

You are correct, that is the same directory that I have been testing with before. It did not actually finish reading this time around, before Finder was able to show the contents of that directory, the mount was stopped.

Certainly, I have linked it for you here

Can I do something else to generate better logs?

22

I have had precisely the same problem that you are having since "upgrading" to Big Sur. Never had any mount issues prior to Big Sur.

After recently connecting to a SMB server directly (no rclone) I noted the same behavior (forced unmount after random N minutes). This suggests that the problem might be entirely related to Big Sur.

Attempted solution #9458.B29 (jkjk)
I added a .metadata_never_index file to the mount-root of both the SMB server and the rclone mount. They have now been up for a few hours without unmounting. Will keep an eye on it.

=== for reference ===
Mac OS Bug Sur 11.2.1
rclone v1.55.0-beta.5191.5b84adf3
MacFuse beta 4.05

@ncw
UPDATE - It's now been up almost 8 hours and both the rclone and smb mounts are stable. Will look again tomorrow ... but seems promising. .metadata_never_index for eliminating spotlight.

Separately, both the rclone and samba mounts are massively more responsive now. Shouldn't be a surprise, as we know how heavy spotlight is. Still, nice.

UPDATE2 - 16 hours and the mounts are still solid :+1:

23

So it seemed to take about 4 minutes to read that directory which has 31,190 items in it.

Directory read started

2021/02/13 15:39:07 DEBUG : /Fotomateriaal/unknown: Readdir: ofst=0, fh=0x8

Kernel gives up (last request from kernel)

2021/02/13 15:41:07 DEBUG : /Fotomateriaal/2020/01/01/_99A9056.CR2.dop: >Access: errc=0

Directory read finishes

2021/02/13 15:43:07 DEBUG : /Fotomateriaal/unknown: >Readdir: items=31190, errc=0

So it looks like the kernel gave up on rclone at the 2 minute mark exactly whereas the directory read took 4 minutes exactly.

This is exactly the setting which --daemon-timeout is supposed to control

 --daemon-timeout duration                Time limit for rclone to respond to kernel. Not supported on Windows.

This is supposed to be 15 minutes for macOS.

Do you see any message like this in the kernel log? That is what OSXFUSE writes when the timeout expires. I think you'll see these messages with dmesg or maybe in /var/log somewhere.

17.11.12 20:02:59.000 kernel: OSXFUSE: force ejecting (no response from user space 5)

Rclone does attempt to set the timeout to 15 minutes, but apparently the maximum is 10 minutes - I saw this in an osxfuse issue. So maybe you could try --daemon-timeout 9m and see if that helps.

I feel like we are making progress, slowly!

1 Like
24

Did you get a chance to try --daemon-timeout 9m - it seemed to help here

1 Like
25

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