Kaizac

Not trying to be ungrateful, but did you manage to push the fix. I got the same error that the archive does not exist. The curl command doesn't seem to solve the issue and am currently without a working rclone. Thanks again!

Did you use port 443 or 444? If you used 443, try using 444.

Yes you are right. DId you follow the linuxserver CHMB guide? And I think the fact you can not access it from your lan when they have their own IP is the key. Maybe you have some setting in your router or lan network going wrong? It's hard to tell with this limited information I'm afraid.

Did you check the ports and whether there is any overlap with other dockers?

I got an error in my config due to the upgrade to Nextcloud 15. I need to run occ command occ db:add-missing-indices. Sorry if it's asked before, search didn't give me anything. How can I run this command? EDIT: sorry I'm being dense, found someone else posted the solution and totally read over it. Through your docker page on Unraid you can open console which puts you in the docker right away. The command: sudo -u abc php /config/www/nextcloud/occ db:add-missing-indices Fixed it.

If you lsd the rclone gdrive and not the mount it doesn't meant the mount went well. But I think I the problem is you are syncing a file and maybe you can only sync folders. See if that's better

If the info you posted is corrected then you called your Gdrive in rclone google-drive-folder. But then in your mount:\ rclone mount --max-read-ahead 1024k --allow-other google1: /mnt/disks/google-drive-myfolder & You mount google1, which doesn't exist. So you either rename your gdrive in rclone config to google1 or you change your mount to google-drive-folder.

Glad you got it working! If you want to use the Gdrive heavily I really recommend to read the topic I linked earlier. The mount command you use now is pretty shitty for performance (not just streaming)

Ah I see it, you missed the & at the end of your mount code. Should be: rclone mount --max-read-ahead 1024k GDrive: /mnt/disks/gdrive &

Sorry for not understanding. What exactly do you expect to happen which doesn't? You say it gets mounted and the commands like sync work. So what is not going right then?

Post your rclone config (remove your tokens and such)

You mean it doesn't finish? Try running it from User Scripts and create a script with the mount command and run it in the background. You can check SpaceInvaders video for that if you want some visual guidance. For the location I don't know if and why Waseh said that, but it's not true. I'm mounting in /mnt/user/ and all my dockers are writing and reading from the mount. For more efficient mounting of Gdrive check this topic, maybe it helps you understand it better.

What do you mean with your rclone mount command never returns? You are mounting as a disk, which it is not, so I think this causes problems. I would advice you to mount to /mnt/users/gdrive or /mnt/users/mounts/gdrive if you want to mount multiple locations later on.

When dockers are not active/moving files in the union folder then you can unmount and remount through running the script in the background. The script will notify you if it succeeded or not. Most reliable is a full restart of the server of course, but not necessary when you are just remounting previous mounts. The sleep is a waiting time build in the execution of the script. Some things need some time to load up properly (like the mounting). This depends on your own server speed and plugins you run. For example I run the Recycle Bin plugin which can take up to 5-10 minutes to load properly. So if you run docker start you need to put in sleeps for that period or that part of the script won't execute. So you just need to experiment a bit with that. What I was asking DZMM is the cron job timing for the mounting script after it started at array. So I have a mount script at start of array. Then I also run the same script every minute again in case of an unmount.

What do you have your remount script set on? I think when an "de-mount" happens it's pretty hard to get a working mount again. Dockers will be moving files to the mount_unionfs folders and rclone will see it as not being empty thus failing. I've put my remount script on 1 minute, to try to mitigate this, but I think there is a big chance it would fail anyways.

That totally depends on your download speed and your processing power of your server. And if you want to stream outside of your home it also depends on your upload speed. If you can mostly direct stream (no transcoding) it will depend 90% on your download/upload speed.

Yeah I've done that from the beginning thankfully own TD with own API. Also I'm keeping all my metadata and subtitles local on a seperate folder from my rclone_upload, to keep rclone scans/uploads fast and limit the amount of cloud folders. Also someone on the rclone forums mentioned the high amount of API hits by Bazarr were a bug and are solved in the development branch. So I've switched to that and my API hits have dropped immensely! So no API bans anymore at the moment :).

Thanks! I discovered that my upload scripts were returned to an previous version and weren't working. Now it's all running as expected again :).

Unfortunately copying/syncing TD to TD is counted as uploading so that's not an option. @DZMM what are your current cront timings on the upload scripts? DId you also create a script for each upload user/API or did you put it in 1 script? I'm getting rate limited and I think it's because Im running an upload script every 20 minutes which gives a lot of api hits due to the checkers.

I know the internal transfers don't count towards quota, but I wonder if it's the same for copying. Tomorrow I will test it with rclone sync, see how fast it is. I think the ban I got today was just an accident because of all the remounting and such. But still Bazarr gives such high API hits (about 200k per day) that it's just a risk. Animosity over on the rclone forums also looked at my logs before and all we can see is that files just get analyzed and opened and closed many times. And it's know that Google doesn't like that behaviour. Plex also has the risk of the same behaviour since Animosity also saw that in his own logs.

Because I want to have a failover when I get API banned. Then I can at least still access my files, whereas now I just can't watch anything which is quite annoying.

@DZMM did you ever experiment with syncing 2 team drives? I can't test it right now because of my ban, so will do that tomorrow. What I'm thinking is to run a full duplicate of the main TD. I'm curious if transfers are near instant and don't count towards the daily quota.

Well you can be (API)banned on upload and download side. Once you get banned on one side the other side still works, which is nice. But I think my bans happened either because I'm both running Emby as Bazarr which are both analyzing files to get subtitles. So I disabled Emby for subtitles now. Other explanation can be that my several reboots and remounts which all used --rc and cached the directory caused problems since Google was seeing too many directory listing. What happens in my case now is that I just can't play videofiles, so it throws an error that it can't open the file. At around 00:00 PST I think it's resetted and everything works again. For now I will keep my API for playback and API for Bazarr seperated, since it does distribute API hits. But I'm afraid the bans happen based on the files itself and not so much based on users/API (the quota are very hard to hit anyways).

I have 3 mounts: Gdrive personal drive, Gdrive Team Drive and Gdrive Team Drive for Bazarr. So I've just tested it with another of my API's and it also gives problems playing media on Gdrive. Some media plays (but this is more recent media, not sure why that matters). So it seems that bans happen on the Team Drive and not on API/user level. That's really unfortunate cause Bazarr is a great piece of software, but getting banned at random is really back.

@DZMM just noticed my other mounts were not working while the main one (which has --rc) does. When I put in the mount command on itself it works. Was that also what you were experiencing and why you removed --rc? EDIT: seems like it was glitching out that not all mounts commands came through. So I put in a sleep between every mount and rebooted and it worked now. I am always getting a docker daemon error on startup though. I've already put in a sleep of 60 seconds but that doesn't seem to solve it. You don't have this issue? Strangely enough I just got API banned it seems and both API's are not working to stream. So maybe the ban happens on TD level and not on API/user level.