Rclone can't create file system

What is the problem you are having with rclone?

When I try to run bisync I get the error message that rclone can't create a file system

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

rclone v1.65.0
- os/version: Microsoft Windows 11 Home 23H2 (64 bit)
- os/kernel: 10.0.22631.2861 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.21.4
- go/linking: static
- go/tags: cmount```

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


#### The command you were trying to run (eg `rclone copy /tmp remote:tmp`)  
<!--  You should use 3 backticks to begin and end your paste to make it readable.   -->

rclone bisync --resync QuickAccess: "U:\Documents\OneDrive1" --user-agent "ISV|rclone.org|rclone/1.65.0" --config "U:\Settings\Rclone\config" --cache-dir "U:\Settings\Rclone\cache" --workdir "U:\Settings\rclone\cache\bisync" --temp-dir "U:\Settings\Rclone\temp"


#### Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.
<!--  You should use 3 backticks to begin and end your paste to make it readable.   -->

[QuickAccess]
type = onedrive
token = XXX
drive_id = XXX
drive_type = business

#### A log from the command that you were trying to run with the `-vv` flag  

2023/12/14 10:44:27 Failed to create file system for "QuickAccess:": didn't find section in config file

You do not have remote called QuickAccess: configured in your rclone.conf file.

maybe you run one command as a regular user and another one as admin...

But QuickAccess is in the config file as can be seen in the results of rclone config redact... How can it not be there? I tried running the command without the : and that didn't work...
Blessings

it is in some rclone.conf file... does not mean it is in the one rclone tries to use

run your command with debug log level:

rclone bisync --resync QuickAccess: "U:\Documents\OneDrive1" --user-agent "ISV|rclone.org|rclone/1.65.0" --config "U:\Settings\Rclone\config" --cache-dir "U:\Settings\Rclone\cache" --workdir "U:\Settings\rclone\cache\bisync" --temp-dir "U:\Settings\Rclone\temp" --log-level DEBUG

and post full output here

2023/12/14 12:35:40 Failed to create file system for "QuickAccess:": didn't find section in config file

This is the full output...

When I tried the command without the : I get a different error.

2023/12/14 12:39:49 Failed to bisync: prior lock file found: C:\Users\Graeme\AppData\Local\rclone\bisync\U__Documents_z_Graeme_and_Helen_QA_files_QuickAccess3.0_QuickAccess..U__Documents_OneDrive1"_--user-agent_ISV|rclone.org|rclone_1.65.0_--config_U__Settings_Rclone_config_--cache-dir_U__Settings_Rclone_cache_--workdir_U__Settings_rclone_cache_bisync_--temp-dir_U__Settings_Rclone_temp_--log-level_DEBUG.lck

It is not.

Add --log-level DEBUG flag

This was the command:

rclone bisync --resync QuickAccess: "U:\Documents\OneDrive1\" --user-agent "ISV|rclone.org|rclone/1.65.0" --config "U:\Settings\Rclone\config" --cache-dir "U:\Settings\Rclone\cache" --workdir "U:\Settings\rclone\cache\bisync" --temp-dir "U:\Settings\Rclone\temp" --log-level DEBUG

This was the output:

2023/12/14 12:43:03 Failed to create file system for "QuickAccess:": didn't find section in config file```

I ran

rclone config redacted --config "U:\settings\rclone\config"

The output was

[QuickAccess]
type = onedrive
token = XXX
drive_id = XXX
drive_type = business
### Double check the config for sensitive info before posting publicly

run

rclone lsf --config "U:\Settings\Rclone\config" -vv

and post output here

When I added the remote name I got this:

2023/12/15 10:50:03 DEBUG : Creating backend with remote "QuickAccess:"
2023/12/15 10:50:03 DEBUG : Using config file from "U:\\Settings\\Rclone\\config"
2023/12/15 10:50:03 DEBUG : OneDrive root '': Token expired but no uploads in progress - doing nothing
2023/12/15 10:50:03 DEBUG : QuickAccess: Loaded invalid token from config file - ignoring
2023/12/15 10:50:03 DEBUG : Saving config "token" in section "QuickAccess" of the config file
2023/12/15 10:50:03 DEBUG : Keeping previous permissions for config file: -rw-rw-rw-
2023/12/15 10:50:03 DEBUG : QuickAccess: Saved new token in config file
2023/12/15 10:50:04 DEBUG : Graeme @ WI: OneNote file not shown in directory listing
2023/12/15 10:50:04 ERROR : : error listing: unknown object type <nil>
2023/12/15 10:50:04 DEBUG : 7 go routines active
2023/12/15 10:50:04 Failed to lsf with 2 errors: last error was: error in ListJSON: unknown object type <nil>```
When I deleted the offending file that apparently is a problem for this command as well I got this:
```2023/12/15 10:53:56 DEBUG : rclone: Version "v1.65.0" starting with parameters ["rclone" "lsf" "QuickAccess:" "--config" "U:\\Settings\\Rclone\\config" "-vv"]
2023/12/15 10:53:56 DEBUG : Creating backend with remote "QuickAccess:"
2023/12/15 10:53:56 DEBUG : Using config file from "U:\\Settings\\Rclone\\config"
Apps/
Attachments/
###
2023/12/15 10:53:57 DEBUG : 5 go routines active```
I took out the list of personal files that are in the cloud.

OK so it works fine. unknown object type <nil> is known problem in v1.65. Already fixed in beta. Most important is that config file is used properly.

Now can you run:

bisync --resync QuickAccess: "U:\Documents\OneDrive1\" --config "U:\Settings\Rclone\config" -vv

As before I got the same output
2023/12/15 12:03:30 Failed to create file system for "QuickAccess:": didn't find section in config file
Should I in fact have QuickAccess and not QuickAccess:?
This seemed to work a little further once before? The output is:

2023/12/15 12:05:36 Failed to bisync: prior lock file found: C:\Users\Graeme\AppData\Local\rclone\bisync\C__Users_Graeme_QuickAccess..U__Documents_OneDrive1"_--config_U__Settings_Rclone_config_-vv.lck```

This behaviour is very bizarre.

I do not have Windows computer at the moment to try it myself.

Maybe it fails due to known onedrive issues in v1.65?

Can you try the same bisync command with the latest beta? v1.66

It should be "QuickAccess:" the one without : uses local dir called QuickAccess

2023/12/15 12:05:36 Failed to bisync: prior lock file found: C:\Users\Graeme\AppData\Local\rclone\bisync\C__Users_Graeme_QuickAccess..U__Documents_OneDrive1"_--config_U__Settings_Rclone_config_-vv.lck```

You may already know this, but -- this error indicates that Bisync thinks a previous bisync process (of these two paths) is still running, and it is locking you out intentionally for safety. This can sometimes happen if a prior run was interrupted before it could finish. (More info)

If you're sure it's a false positive, you can override it by simply deleting the file and trying again. This should do it:

rclone deletefile 'C:\Users\Graeme\AppData\Local\rclone\bisync\C__Users_Graeme_QuickAccess..U__Documents_OneDrive1"_--config_U__Settings_Rclone_config_-vv.lck'

Also, for whatever it's worth -- I just this week opened a PR to improve the behavior in exactly this kind of situation :slight_smile:

I tried the same command after deleting the problematic file. I was able to run size correctly but running the bisync gave the same error result. From the other input it seems that running it without the : is not correct in this case and therefore there is no need to remove the file that was given as a lock file.
I don't know how to resolve this issue.

I managed to reproduce this just now (on Windows only), and I think the problem is the trailing slash at the end of "U:\Documents\OneDrive1\". Windows uses \ instead of the / used by most other OSs, and I think it is confusing Bisync. Can you give it a try without the trailing slash and let me know if it solves the problem? If so, this is something I'd like to fix in a future version.

In other words, instead of:

"U:\Documents\OneDrive1\"

try:

"U:\Documents\OneDrive1"
1 Like

It worked! Although it did say that bisync is EXPERIMENTAL and NOT to use it in production... is that still current?

Glad to hear it! I will open an issue to improve this going forward -- should be an easy fix.

Yes and no... I think "beta" and "advanced command" are better descriptions for it than "experimental", for reasons I described in more detail here. Bisync sat unmaintained for quite awhile after it lost its original maintainer, and the label was deserved at that time, but now I have taken it on and am actively patching a lot of the old bugs, like the one you just discovered :slight_smile: I hope that bisync can graduate from "beta" in the not-too-distant future. Until then, some caution is certainly warranted (and it doesn't replace the need for a good backup system), but I think the log warning is a bit hyperbolic at this point. I've been using it in production myself for quite awhile now without any major incidents. (I do find small bugs from time to time, but then I fix them :slight_smile: )

The one thing I will say is that it's definitely important to read the manual in detail and make sure you understand how it works, as sometimes people come to bisync with assumptions from other sync tools and are surprised to learn that bisync does some things differently!