DZMM

I've updated my scripts on github to fix a few issues people have been having, notably removing the rc command as I think it causes more problems than it's worth https://github.com/BinsonBuzz/unraid_rclone_mount

1. Plex treats gdrive files the same as it does local files, so it will use the same rules as to whether or not to direct play, transcode etc 2. as above - Plex does the work 3. No - if you have decent bandwidth you will hardly see a difference e.g. my cloud files launch in an average of about 5 seconds - some faster, some slower, which is a bit longer than it takes for a local disk to spinup

no - something must have gone wrong with your first mount - there normally shouldn't be anything in the unionfs folder before you mount

you've got something in mount_unionfs so the mount failed. Check what it is, delete and then run fusermount -uz /mnt/user/mount_unionfs/google_vfs unionfs -o cow,allow_other,direct_io,auto_cache,sync_read /mnt/user/rclone_upload/google_vfs=RW:/mnt/user/mount_rclone/google_vfs=RO /mnt/user/mount_unionfs/google_vfs in a temporary script

I don't quite understand some of the errors google throws out - you can't be over your upload limit as your mount is empty. As @nuhll says, it will fix itself soon. There's nothing to worry about as your usuing your own client_ID not the shared rclone one. your mount is working which is the main thing, so start uploading via the rclone_upload folder not by adding direct to the mount folder

yes. When unionfs 'deletes' a file from the RO directory, it doesn't actually delete the file it just hides it in the mount. What the script does is actually delete the files from the RO directory and then tidy up the hidden unionfs directory. For the RW directory it can delete the files, so the script doesn't need to do anything there.

That was for @nuhll (i) I think because you've got a mountcheck file in rclone_upload it's messing up the unionfs mount as it seeing two copies of the same file in two places. (ii) I'm not sure why the rclone_mount is empty though. Try this: 1. manually delete the encrypted mountcheck file on google drive and empty the trash just to be certain it's gone 2. delete the local file in rclone_upload 3. recreate the mountcheck file using touch in terminal 4. create a quick new temp script to unmount and remount Edit: remember to run script in the background #!/bin/bash fusermount -uz /mnt/user/mount_unionfs/google_vfs fusermount -uz /mnt/user/mount_rclone/google_vfs rclone mount --allow-other --buffer-size 512M --dir-cache-time 72h --drive-chunk-size 512M --fast-list --log-level INFO --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit off gdrive_media_vfs: /mnt/user/mount_rclone/google_vfs & sleep 5 unionfs -o cow,allow_other,direct_io,auto_cache,sync_read /mnt/user/rclone_upload/google_vfs=RW:/mnt/user/mount_rclone/google_vfs=RO /mnt/user/mount_unionfs/google_vfs exit

Check my last reply - I updated it for you!

1. there's nothing in your crypt except your mountcheck file..... 2. you shouldn't be seein the mountcheck file in rclone_upload/google_vfs though as it's already in the cloud. What does your /mnt/user/mount_rclone/google_vfs look like?

Hmm. everything looks correct. Apologies if these questions seem obvious: 1. Are you definitely using the right password and password2? 2. the files that are already in gdrive are encrypted (goobledegook when you look in google)? 3. Are the google files in a folder called crypt on google i.e. not encrypted so you can see my drive/crypt when you look at Google?

no - just substitute in your existing remote name in the mount script for my gdrive_media_vfs remote. Or, rename the remote in rclone config might be easier

post your rclone config (remove passwords and IDs) and mount script

Unionfs is useful is if you want to add one monitored folder for sonarr & radarr that combines files that are on your local drive with files that have already been uploaded e.g. if you had tv_show1 spread across /mnt/user/rclone_upload/google_vfs/tv_shows/tv_show1 and /mnt/user/mount_rclone/google_vfs/tv_shows/tv_show1 sonarr can only monitor one folder at a time, so if when files are moved to the cloud it would think they are missing and download them again, meaning you could end up with multiple copies on the cloud. Also, sonarr wouldn't be able to upgrade files. For radarr, the problems are similar. Even if you're not using radarr or sonarr and you are just using Plex, it's cleaner to add the unionfs folder to Plex rather than both the upload and cloud folder, because plex won't waste time re-scanning files when it spots they've moved to the cloud, as to plex they won't have moved as the unionfs folder 'masks' the real location

@Kaizac how are you getting on with your td-->td transfers? I'm still nervous about doing them e.g. I just moved a two movie folders between td1/adults/ td1/kids using putty and the folders moved ok, but the file inside disappeared! I just did moved an individual file using putty and that went ok. I think I'm going to stick with consolidating all my files to gdrive once they've uploaded and doing my moves/edits there. The lesson here is make sure everything is organised correctly before uploading. Edit: Looks like it was a false alarm. Not sure what how, but the file was also in td2/adults - the file in td1/adults must have been a phantom or something....I just did the same transfer from td2/adults to td2/kids and all was ok - phew!

It won't work for you as you've added a 2nd RO directory. You need: find /mnt/user/mount_unionfs/google_vfs/.unionfs -name '*_HIDDEN~' | while read line; do oldPath=${line#/mnt/user/mount_unionfs/google_vfs/.unionfs} newPath=/mnt/user/mount_rclone/google_vfs${oldPath%_HIDDEN~} newPath1=/mnt/user/rclone_upload/google_vfs${oldPath%_HIDDEN~} rm "$newPath" rm "$newPath1" rm "$line" done find "/mnt/user/mount_unionfs/google_vfs/.unionfs" -mindepth 1 -type d -empty -delete Just add another move: rclone move /mnt/user/Archiv/Musik gdrive_media_vfs:Musik -vv --drive-chunk-size 128M --checkers 1 --fast-list --transfers 4 --exclude .unionfs/** --exclude *fuse_hidden* --exclude *_HIDDEN --exclude .recycle** --exclude *.backup~* --exclude *.partial~* --delete-empty-src-dirs --fast-list --tpslimit 3 --min-age 8y && rclone move /mnt/user/Archiv/Serien gdrive_media_vfs:Serien -vv --drive-chunk-size 128M --checkers 1 --fast-list --transfers 4 --exclude .unionfs/** --exclude *fuse_hidden* --exclude *_HIDDEN --exclude .recycle** --exclude *.backup~* --exclude *.partial~* --delete-empty-src-dirs --fast-list --tpslimit 3 --min-age 8y I haven't uploaded music and I'm not sure if that's a good idea as even an extra pause of a second between tracks would be annoying. Let me know what the experience is like as I'm curious. There's something odd about the file permissions - just delete manually via terminal

use the commands via ssh to create the mountcheck file and to transfer it's foolproof. If you're not seeing your other files then something's gone wrong with your encryption - are you sure the new vfs mount is using the same keys as your old encrypted mount?

You can copy files directly to the mount, but it's better to use rclone move as it retries if there's an error. What unionfs does is create a merged folder for plex that combines local files + cloud files in one directory, so you don't get issues in plex like it thinking files are missing, getting confused when files have been upgraded etc. If you are just copying completed files to rclone you should just modify the upload script i.e.: rclone move /mnt/source_folder/ gdrive_media_vfs:destination_folder -vv --drive-chunk-size 512M --checkers 3 --fast-list --transfers 2 --exclude .unionfs/** --exclude *fuse_hidden* --exclude *_HIDDEN --exclude .recycle** --exclude *.backup~* --exclude *.partial~* --delete-empty-src-dirs --fast-list --bwlimit 9500k --tpslimit 3 --min-age 30m Edit: has your playback improved?

@francrouge also, rc keeps running after your first mount attempt, so if you are trying a second mount attempt without rebooting it will always fail unless you remove --rc i.e. run: rclone mount --allow-other --buffer-size 512M --dir-cache-time 72h --drive-chunk-size 512M --fast-list --log-level INFO --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit off gdrive_media_vfs: /mnt/user/mount_rclone/google_vfs & I'm trying to find a way to stop rc in the unmount script to stop this problem tripping people up

Did you create the mountcheck file? touch mountcheck rclone copy mountcheck gdrive_media_vfs: -vv --no-traverse

It worked for me as well one day and then it stopped - I think maybe the checks on teamdrives aren't as stringent. I'm going to stick with my new distributed layout as it makes it easier for my cleanup script to work and for me to move files around. E.g. here's my new clean-up script that looks at each media type in each teamdrive: echo "$(date "+%d.%m.%Y %T") INFO: starting unionfs cleanup." # gdrive - movies find /mnt/user/mount_unionfs/google_vfs/.unionfs/movies -name '*_HIDDEN~' | while read line; do oldPath=${line#/mnt/user/mount_unionfs/google_vfs/.unionfs/movies} newPath=/mnt/user/mount_rclone/google_vfs/movies${oldPath%_HIDDEN~} rm "$newPath" rm "$line" done # tdrive_rclone1 - tv find /mnt/user/mount_unionfs/google_vfs/.unionfs/tv -name '*_HIDDEN~' | while read line; do oldPath=${line#/mnt/user/mount_unionfs/google_vfs/.unionfs/tv} newPath=/mnt/user/mount_rclone/tdrive_rclone1_vfs/tv${oldPath%_HIDDEN~} rm "$newPath" rm "$line" done find "/mnt/user/mount_unionfs/google_vfs/.unionfs" -mindepth 1 -type d -empty -delete

lol see the post I just did - you need to use multiple tdrives the quota is 750GB/day per team drive. Not a big issue as each takes 5 mins to setup. I'm doing my td-->td transfers as much as possible within gdrive. What I've noticed so far in mc is if you are overwriting files it takes as long as downloading, but if you move it's pretty much instantaneous - so just make sure the destination directory is empty

You encountered the same problem as me that I've just fixed. The info I read on Team Drive limits was wrong - it's 750GB/day per team drive not per user, as well as 750GB/day per user. https://support.google.com/a/answer/7338880# What I've done to fix this is create 3 team drives and then spread my media folders across them e.g.: gdrive: tv shows td1: movies td2: movies_uhd etc etc Edit: with still unique token/client_id per team drive The reason I've separated media types across team drives is I want to make it easier to move files within google so I don't have to download to reupload or end up with duplicate folders......I noticed yesterday that if I moved tv_show1/season1/episode_6 from td1 to gdrive where there's already a tv_show1/season1 folder it would create a new tv_show1/season1 folder with tv_show1/season1/episode_6 in it rather than adding episode_6 to the existing folder. This was causing havoc with the mount, so by splitting my media folders I will reduce the number of times I will have to move files between team drives.

have a read of the first couple of posts and check my scripts on github that are fairly up to date (just need to tweak the teamdrive bits). If you're still stuck, there's a few people in this thread who will help. You need to do a vfs mount for streaming.

Not media file related, but just sharing how I backup to gdrive my local /mnt/user/backup share where I keep my VM backups, CA appdata backup, cloudberry backup of important files from other shares etc rclone sync /mnt/user/backup gdrive_media_vfs:backup --backup-dir gdrive_media_vfs:backup_deleted -vv --drive-chunk-size 512M --checkers 3 --fast-list --transfers 3 --exclude .unionfs/** --exclude *fuse_hidden* --exclude *_HIDDEN --exclude .recycle** --exclude *.backup~* --exclude *.partial~* --delete-empty-src-dirs --fast-list --bwlimit 10000k --tpslimit 3 --min-age 30m rclone delete --min-age 90d gdrive_media_vfs:backup_deleted --bwlimit 10000k sync keeps a copy in the cloud of my files. Any files deleted or moved locally that have already been synced are moved to the backup_deleted directory on gdrive: --backup-dir gdrive_media_vfs:backup_deleted where they are deleted after 90 days: rclone delete --min-age 90d gdrive_media_vfs:backup_deleted --bwlimit 10000k