Cannot mount google drive anymore - Fatal error: mount not ready

What is the problem you are having with rclone?

As of yesterday my usual rclone command I've been using for years has stopped working and I cannot mount my google drive anymore. I run the command and it outputs "Fatal error: mount not ready"

Run the command 'rclone version' and share the full output of the command.

rclone v1.57.0-DEV

  • os/version: gentoo 2.7 (64 bit)
  • os/kernel: 5.4.80-gentoo-r1-whatbox (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.17.5
  • go/linking: dynamic
  • go/tags: none

Which cloud storage system are you using?

Google Drive

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

rclone -v mount --daemon --daemon-timeout=5m --allow-non-empty --buffer-size=32M --use-mmap --dir-cache-time=84h --cache-info-age=168h --vfs-cache-mode=minimal --vfs-read-chunk-size-limit off --vfs-cache-max-age=6h --vfs-read-chunk-size=32M gdrive: ~/pdrive/

The rclone config contents with secrets removed.

[gdrive]
type = drive
client_id = redacted.apps.googleusercontent.com
client_secret = redacted
scope = drive
token = {"access_token":redacted}
root_folder_id = 0AJQSFqbVFzSDUk9PVA

A log from the command with the -vv flag

rclone -vvv mount --daemon --daemon-timeout=5m --allow-non-empty --buffer-size=32M --use-mmap --dir-cache-time=84h --cache-info-age=168h --vfs-cache-mode=minimal --vfs-read-chunk-size-limit off --vfs-cache-max-age=6h --vfs-read-chunk-size=32M gdrive: ~/pdrive/
2022/01/14 03:51:33 DEBUG : rclone: Version "v1.57.0-DEV" starting with parameters ["rclone" "-vvv" "mount" "--daemon" "--daemon-timeout=5m" "--allow-non-empty" "--buffer-size=32M" "--use-mmap" "--dir-cache-time=84h" "--cache-info-age=168h" "--vfs-cache-mode=minimal" "--vfs-read-chunk-size-limit" "off" "--vfs-cache-max-age=6h" "--vfs-read-chunk-size=32M" "gdrive:" "/home/shiftgaming/pdrive/"]
2022/01/14 03:51:33 DEBUG : Creating backend with remote "gdrive:"
2022/01/14 03:51:33 DEBUG : Using config file from "/home/shiftgaming/.config/rclone/rclone.conf"
2022/01/14 03:52:33 DEBUG : Daemon timed out. Terminating daemon pid 49063
2022/01/14 03:52:33 Fatal error: mount not ready

Using a broken packaged build.

Install (rclone.org)

Remove what you got and install from the link above.

Just for education, what part of the logs show the build is broken, so I can know for future?

That tells me your OS.

That tells me it is the packaged version with Gentoo.

I have 1.57.0 , isn't that the latest?

No, you have a packaged version from Gentoo, not the latest official.

I'm running on a whatbox.ca seedbox, I won't be able to change the install. Should I just give up using the daemon and run it in screen?

Download:

Rclone downloads

Install somewhere and run from the location. No root is needed.

You can do whatever you want in the end, but we don't support custom versions. You'd want to check with whoever built it / maintains it.

The 1.57 version official looks like:

rclone version
rclone v1.57.0
- os/version: ubuntu 20.04 (64 bit)
- os/kernel: 5.11.0-46-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.17.2
- go/linking: static
- go/tags: none

Basically, you have no idea what that package is or what changed or what they did or did not do.

I got the release from Here
I put rclone in /mnt/mpathn/shiftgaming/bin/ - it did not exist there before.

Then ran this to check

/mnt/mpathn/shiftgaming/bin/rclone version

rclone v1.57.0

  • os/version: gentoo 2.7 (64 bit)
  • os/kernel: 5.4.80-gentoo-r1-whatbox (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.17.2
  • go/linking: static
  • go/tags: none

Then here the output

/mnt/mpathn/shiftgaming/bin/rclone -vv mount --daemon --daemon-timeout=5m --allow-non-empty --buffer-size=32M --use-mmap --dir-cache-time=84h --cache-info-age=168h --vfs-cache-mode=minimal --vfs-read-chunk-size-limit off --vfs-cache-max-age=6h --vfs-read-chunk-size=32M gdrive: ~/pdrive/
2022/01/14 04:24:35 DEBUG : rclone: Version "v1.57.0" starting with parameters ["/mnt/mpathn/shiftgaming/bin/rclone" "-vv" "mount" "--daemon" "--daemon-timeout=5m" "--allow-non-empty" "--buffer-size=32M" "--use-mmap" "--dir-cache-time=84h" "--cache-info-age=168h" "--vfs-cache-mode=minimal" "--vfs-read-chunk-size-limit" "off" "--vfs-cache-max-age=6h" "--vfs-read-chunk-size=32M" "gdrive:" "/home/shiftgaming/pdrive/"]
2022/01/14 04:24:35 DEBUG : Creating backend with remote "gdrive:"
2022/01/14 04:24:35 DEBUG : Using config file from "/home/shiftgaming/.config/rclone/rclone.conf"
2022/01/14 04:25:35 DEBUG : Daemon timed out. Terminating daemon pid 31738
2022/01/14 04:25:35 Fatal error: mount not ready

same result it seems

If they have a custom build and a custom kernel, you probably want to check with them for support as they are most likely doing something 'unique' and a forum searches has the same issue from a few other folks.

felix@gemini:~$ rclone mount GD: /home/felix/test -vvv --daemon
2022/01/13 23:36:44 DEBUG : Setting --config "/opt/rclone/rclone.conf" from environment variable RCLONE_CONFIG="/opt/rclone/rclone.conf"
2022/01/13 23:36:44 DEBUG : rclone: Version "v1.57.0" starting with parameters ["rclone" "mount" "GD:" "/home/felix/test" "-vvv" "--daemon"]
2022/01/13 23:36:44 DEBUG : Creating backend with remote "GD:"
2022/01/13 23:36:44 DEBUG : Using config file from "/opt/rclone/rclone.conf"
2022/01/13 23:36:45 DEBUG : rclone: Version "v1.57.0" finishing with parameters ["/usr/bin/rclone" "mount" "GD:" "/home/felix/test" "-vvv" "--daemon"]
felix@gemini:~$ uname -a
Linux gemini.animosity.us 5.11.0-46-generic #51~20.04.1-Ubuntu SMP Fri Jan 7 06:51:40 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
felix@gemini:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

There was an issue pre 1.57 that was related to the daemon so my initial thought was a build issue, but that seems to not be the case as you validated a proper / released build.

@ivandeex - any thoughts or anything else to grab? I can tell the kernel is custom as well and not sure how far down the rabbit hole to go...

@Matt_Deezly - short term, I would use screen / tmux as you suggested.

Start from removing complexity and adding diagnostics.
Rerun command with -vv --log-file helpme.log and without --daemon. This time rclone will not exit but sit on mount silently like a hen on eggs.
Reproduce the issue and send the log here. If it's big then upload it somewhere and paste here the link.

hi,
there have a been a number of posts recently about wackbox, gootoo linux, dev versions of rclone and fatal error with rclone mounts.

for example,
https://forum.rclone.org/t/rclone-fatal-error-mount-not-ready/28385/118

Whatbox is amazing and I've been using them for over 8 years. Super stable (besides this, which is the first issue i've had in my 8 years). I get 2Gbps easily on my DL for torrents. When using plex I've ran up to 10 4K transcodes at once and it ran perfectly too. Their servers communicate really well with plex friends I have in Japan and other countries far far away. - - I really don't think they're bad. At least in my experience

i guess you did not read that topic i shared or missed the posts about recent changes with whatbox and rclone?

given that your are the second rcloner to have recent issues with whatbox, might contact them.

Ask them for support on their compiled version of rclone and let me know the response.

Not sure I want to debate this one as the power needed for 10 4K transcodes is quite a bit. From their support page:

I've used them in previous lives and they are a good provider. I just don't quite get what they are doing with rclone and what customizations that they've built in as it's a compiled version not stock so not saying they are doing anything malicious, but I wouldn't use their version.

Sorry I just woke up, ill take a look @ the topic. Sorry

idk its worked well for me. Anyway, I contacted their support. It seems the issue is as you said, on their end. So thanks for the support here guys !

When I encountered the same error initially, I just ran in on a screen without deamon, it has not given me a problem yet. They eventually updated their guide to use screen instead of deamon too.

Is there a benefit of using deamon over screen? (I am somewhat new to linux and seedboxes)

Nah, not really. Daemon is a bit cleaner, but really doesn't matter. Daemon is just putting the process into the background and it'll run. Screen is something that 'stays' and you are running in that so it survives logging in and logging out and is a very normal thing to do.

I see, thanks for the explanation. For seedboxes, it doesn't seem to matter much since users do not really log in or log out. Anyways, thank you for this amazing software :slight_smile: