I use systemd service to mount my OneDrive, uploaded new files to it and they showed up in the mounted folder. But after some time, the new files disappeared in the folder. I entered rclone ls test: saw that the uploaded files are still in the remote without problems
I reboot the vps, those previously uploaded files now show up in the mounted folder. But if I upload new files to the mount, after a while, they would disappear again. The new added files won't synchronize to the mount for some reasons
Run the command 'rclone version' and share the full output of the command.
Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.
type = onedrive
token = XXX
drive_id = XXX
drive_type = personal
type = crypt
remote = onedrive:/test1
password = XXX
A log from the command that you were trying to run with the -vv flag
I checked the info log, there are lots of repetitions of the below lines
2023/10/06 01:13:26 INFO : vfs cache: cleaned: objects 2 (was 2) in use 0, to upload 0, uploading 0, total size 7 (was 7)
2023/10/06 01:13:27 INFO : OneDrive root 'test1': Change notify listener failure: invalidRequest: [token.String] A value is required but was not present in the request.
2023/10/06 01:13:42 INFO : OneDrive root 'test1': Change notify listener failure: invalidRequest: [token.String] A value is required but was not present in the request.
2023/10/06 01:13:57 INFO : OneDrive root 'test1': Change notify listener failure: invalidRequest: [token.String] A value is required but was not present in the request.
listener failure: invalidRequest: [token.String] A value is required but was not present in the request.
i do not know why that happens, i did not quick test, could not replicate.
adding --dump can give you a deeper look into what rclone is sending/receiving, so add it to your mount command.
not sure what that means?
can you post some set of commands to document that, how to replicate.
fwiw, for debugging, i find it easier to not use systemd. to use .sh on command line.
I would recommend you try 1.65 beta release. ListR support via delta API is now merged on that revision and fixed a lot of my cache issues plus it made the file list way more reliable. I used to have this issue and had to do a rc call for vs/forget and vfs/refresh every now and resync all the files without remounting, but since using the new method I have not experienced this issue.
use systemd service to mount my remote as described previously
create a local folder in my vps, use mergerfs to merge the local folder and the mounted folder into a new folder. (This new folder is the path of my Plex and relevant apps)
setup a cron job to auto-upload files from the local folder to the mounted folder
Here's what I mean by 'the new files disappeared in the mounted folder'
If I create a new file in the local folder, it gets uploaded into the mounted folder, and I can see it inside the mounted folder within like 2 hours after the upload. Then If I check it again on the 3rd hour, it's not in the mounted folder anymore. I thought it was deleted in the first place, but when I used rclone ls test: the file is still there, so it looks like the mounted folder does not sync with my cloud remote for some reason
Sorry, didn't mean the token.String error directly. But overall OneDrive cache going crazy. Based on my hunch if the mount ever gets throttled, it will eventually go out of sync as the polling will be throttled as well and miss the sync information. Based on my (still limited) testing it seems Microsoft is more relaxed on delta API calls so it won't happen.
Since I have plan to use Google Drive, I test this by creating a new remote. All mount settings in systemd file are the same, except this time I added client id/secret through the remote creating process.
Now there's no syncing issues, all uploaded files are updated in time in the mounted folder. I think I'll stick to this setup now. Although I haven't yet tested rclone beta, it might help if someone were to use onedrive; Or else, adding client id/secret to the remote works. Thank you for these solutions! @asdffdsa@jcastill