Kaizac

You're misunderstanding the way service accounts work. They function as regular accounts. So instead of using your mail account, you use a service account to create your mount. What I did is rename some of the service account files to the mount they represent. You can put them in a different folder. Like sa_gdrive_media.json for your media mount. So for this you will have to not put in the path to the folder with the service account, but to the exact folder. Which you did in your last post. By seperating this you will also not use these SA's for your upload script, seperating any potential API bans. The upload script will pick the first of the service accounts. Then when it finishes because it hits the 750gb api limit it will stop. That's why you put it on a cron job so it will start again with service account 2 until that one hits the api limit. And so on. Just so you understand, the script doesn't just keep running through all your service accounts. You will have to restart it through a cron job. About moving your current folder to your teamdrive. It depends whether the files are encrypted the same as your new team drive mount. So with the same password and salt. If that is the case you can just drag the whole folder from your gdrive to your team drive from the Google Drive website. Saves a lot of time waiting for rclone transfers to finish. You can even do this to transfer to another account. The encryption has to be identical though.

Look at https://github.com/xyou365/AutoRclone/issues/89 You have to edit some code in the script. You can use notepad++ for that.

Try running pip3 install --upgrade setuptools And then run the requirements command again. (don't forget to cd to the right folder again).

What does your unraid terminal show when you type in: python and python3

Why don't you just do this from your Unraid box and use the terminal? Windows complicates stuff. You can get python 3 from the community store. Then just get a folder where you dump all the files in and use "cd /path/to/folder" to get to that folder and execute from there.

It literally says in step 1 that you need to install rclone..... And did you activate the Drive API and get your credentials.json?

Go to your mnt/appdata/other/rclone/remotes/XXyour-remote-nameXX/ folder and you should see a daily_upload_running file there. Delete it and start the script again. It's a checker file like mountcheck, but doesn't get deleted on shutdowns and such. So the script will think it's already running, but with a manual delete it will run again.

I don't know what you mounted and what you mean with Google drive contents not showing up? If you're mounting your crypt you will only see files in the specific team drive and the Crypt folder within that team drive.

Rename your crypt to gdrive_vfs through rclone config and you're good to go.

You can have a different folder name from the remote name, they don't have to be identical. So you just need to create a google drive remote like you did. Then link a crypt remote to it. Like googleworkspace and googleworkspace_crypt. And then you can mount it to folder /mnt/user/mount_mergerfs/gdrive, or whatever name you like. I've explained in one of my recent posts how you should look at the mount script and what you need to put in the variables.

You have to create /user pointing to /mnt/user/mount_mergerfs/gdrive_vfs or whatever naming scheme you use within your docker templates. Then within the dockers itself you have to start all your directories/folders from /user/. For example /user/media/movies. This way all dockers will look at it like it's one drive and thus have the fast performance.

Did you create these through the shell/terminal? Seems you are missing the following for the crypt mount: filename_encryption = standard directory_name_encryption = true Or maybe you don't want those options enabled? The googleworkspace mount seems fine. You could add: server_side_across_configs = true About the 5TB limit. Right now the google workspace accounts are a bit of unclear for new accounts and their storage. The 5TB is the personal drive limit. It will show this for me as well, but I can just go past it (I use team drives). But people with new accounts have also been reporting that they can't upload more than 5TB and you will need 2 more accounts and then ask Google for more storage every time with an explanation. You can upload 750gb per day per account (or use service accounts to have 750gb per service account, but this is a bit too complicated for you right now I think). So you'll just have to test it whether you can go past the 5TB storage.

My mount settings are above in one of my posts. I don't know your download speed, but if it isn't that high you might be downloading too big of a chunks or too far ahead. And your dir-cache-time can be 9999h. Regarding your second question, what do you mean with direct play? Normally direct play within the plex context means that your client device (media player) is playing the files directly, without any transcoding needed. So that is definitely possible, just depends on your mediaplayer. Playing a 4K on a chromecast 1080p will lead to a transcode of course. And a lot of burned in subtitles also lead to transcoding for the subtitles part, but not the video part. For your samba issues I would suggest you reboot without anything mounted, no dockers on and such. And then just put in a file in your mount_mergerfs folder an see whether you can open and edit that file.

Did you update to the latest stable? They fixed something with samba again.

No problem, but I think it shows that you are rate limited so it will keep trying until the limitation is gone again. I don't understand why you added --max-transfer? You already have --drive-stop-on-upload-limit, so that will end the script when you hit the limit. Maybe try removing your max-transfer flag and see what the script does?

Glad it works now! Regarding the encryption, I meant you don't do file or directory name encryption. And you made clear that's a deliberate choice. I was just surprised with that. Knowing that Google has been limiting new accounts and stopping unlimited storage and multiple stories of people who got their whole drive deleted because of copyright material. I personally don't want to take that risk.

Krusader working is not surprising since it uses the root account, so it's not limited with permissions. I looked over your scripts quickly and I see nothing strange. So I think it's an samba issue. Did you upgrade to 6.11? There were changes to sambe in there, maybe check that out? Could explain why it stopped working. Wow, I'm amazed your script for Server A worked.... You configured your Gcrypt as : gsuite:/crypt/media. But the correct method would be gsuite:crypt/media. Then you also had your cache-dir in your A script to /cache. Did that work? In unraid you will have to define the actual path. Seems you did that correctly in the new script. On the A script you didn't close the mount script with a "&", in the new script this is fixed already by default. In your new script you put in --allow-non-empty as extra command, this is very risky to do. So make sure you thought about doing that. What I find most worrying is that your crypt doesn't actually encrypt anything. Is that by choice? If you do want to switch to an actually encrypted Crypt you will have to send all your files through the crypt to your storage. It won't automatically encrypt all the files within that mount. Your specific questions: 1. Don't use "Run script" in User Scripts. Always use run script in the background when running the script. If you use the run script option it will just stop the script as soon as you close the popup. That might explain why your mount drops right away. 2. You have the rclone commands here: https://rclone.org/commands/. Other than that you can for example use "rclone size gcrypt:" to see how big your gcrypt mount is in the cloud. 3. You can unmount with fusermount -uz /path/to/remote. Make sure you don't have any dockers or transfers running with access to that mount though, because they will start writing in your merger folder causing problems when you mount again.

It's a pretty common issue throughout the latest topics. It's probably because the files are owned by root. Did you check the files permissions which you try to open?

Maybe just add a chown command at the end of the script somewhere before the last exit? chown -R nobody:users /mnt/user/local

1. I would put all the shares you only use to mount cloud stored files on (so nothing locally, or not much) to Prefer cache. It prevents to disturb your array disks from sleeping or having to switch read/write which is slow on a HDD. Other than that it looks fine 2. Let me state beforehand I don't use torrents, so this is a part of your workflow I don't use personally. However I wonder why you want to upload files before seeding? You could decide to add the Torrent share to your merged folder of local/cryptmedia cloud/torrents. But you have to be aware of using the right folder structures. Maybe you can combine local and torrents and you only have (local/torrents) and (cloud) as 2 folders that are merged. Plex would still see the file the same since it's part of mount_mergerfs. It's up to you though. Regarding the folders in the script, these are folders that will be created in local folder in case they are not already there. I don't use DZMM's mount script because I have a bit of a different use case. But I also don't create folders within the main folders. I only have local, mount_rclone and mount_mergerfs. But like I said, I don't upload everything like he and you do. So you can try it out, with or without that list of folders. If you don't want to use that command, just remove the folder names or put in 1 dummy folder name. Don't just delete the whole line, that will mess up the script. 3. Leave the top parameters, delete the flags further down in the script with the list of -- XX flags. Keep dir-cache-time and attr-timeout, but remove cache-dir. Dir-cache is different than VFS cache. Delete: --cache-dir=$RcloneCacheShare/cache/$RcloneRemoteName \ --vfs-cache-mode full \ --vfs-cache-max-size $RcloneCacheMaxSize \ --vfs-cache-max-age $RcloneCacheMaxAge \ --vfs-read-ahead 1G \ Just FYI, I use these values for my mount script which differ a bit from DZMM: --allow-other --umask 002 --buffer-size 256M --dir-cache-time 9999h --drive-chunk-size 512M --attr-timeout 1s --poll-interval 1m --drive-pacer-min-sleep 10ms --drive-pacer-burst 500 --log-level INFO --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit off After the share rclonecache is empty you can just delete it yes. Make sure you reboot after all the changes, so the cache is also actually stopped. Even better is to disable your dockers and mount script, reboot and then make the changes and delete the share and then start everything up. 4. You use copy instead of move, any reason for that? These parameters are a bit ambiguous and can go wrong easily if you have a different setup/naming scheme. So to explain: RcloneRemoteName= This is the foldername where everything is stored. So if your crypt mount name (cryptmedia) is the same as the folder in your local and mount_mergerfs folders this is fine. But for example if your rclone mount is crypt_media: but your folder is actually mount_mergerfs/Crypt-Media you have to fill in Crypt-Media here. RcloneUploadRemoteName= use your actual rclone mount name here, not the folder name. LocalFilesShare= location of the local files, so yours is fine like this RcloneMountShare= this is the main folder directory in which the folder to which you mount the rclone mount is nested. So in your case you used "/mnt/user/cryptmedia". But that means the script as you configured it now will upload files from "/mnt/user/cryptmedia/cryptmedia". If that is correct, then no problem. But if your media folder structure starts directly in the share cryptmedia you would have to fill in "/mnt/user" here. Remove -vv at command 2. It's already part of the default upload script as you can see further down below.

1. I see you have the shares Gsuite, Cryptmedia, Rclonecache, local, mount_mergerfs. I don't understand the purpose of these. Normally you would only have 3 or 4 if you also use VFS cache. In the traditional setup you would have 1 folder to which you mount your crypt of google drive (mount_rclone in the script). Then you have your local files (mnt/user/local in the script) and the merger folder of those 2 (mount_mergerfs in the script). 2. This is where your share structure also confuses me. You don't use the local share in your mount script, you put it on ignore. So your current setup will just use the mounted crypt rclone mount and the rclone cache. Your local files are not included in the merger. This means you are working fully in the cloud and don't have any of your media associated files locally. I personally store the small files like subtitles and nfo and artwork locally and merge that share with my cloud mount. 3. Like you did right now, the Share rclonecache only uses Disk 1. Just know that the depending on your setup/wan speed/amount of users the rclone cache advantage can be pretty small. I used to use it, but I stopped and don't notice any difference, even though it uses a lot of storage. And I even stored it on an SSD. Putting a cache on a HDD can work, but I'm not really sure you are really getting the advantages you desire. To explain the cache: without cache you play a media file and it will write the buffer to your RAM and will play from there, thus initiating a new download every time the file is accessed. With cache: the buffer will be written to your VFS cache-dir disk and from there it will play. If you access that file later again it will play from your cache instead of downloading again. This can be useful when you have a multiple people accessing the same media and it prevents having to download the file every time when someone start the media playback and is easier on your RAM. But if you just have a few users or have different media interests it will just download Episode 1 to the disk, then you play Episode 2, Then episode 3, etc. And then once the cache is full it will just delete the unused cache files. There won't be any advantage because nobody is looking at Episode 1 within a short time span again. So take your situation in consideration before you take on the hassle to get a cache working. vfs-read-ahead only works with vfs-cache-mode full, so when you don't use the cache you don't need this flag. 4. My upload script has -vv in it and this shows me what's going on when I look at the log within the User Scripts section of Unraid.

Your shares are all over the place to be honest. And your disk 1 which you use for all your shares is almost completely full which will just lock up your whole system. Right now your mount config seems to be fully cloudbased, without any local files. Is that correct? But you are using VFS cache on a disk which you use for all your other media/storage. That's really not advisable. Normally you use an unassigned drive for the cache so it does not interfere with your main storage/processes. So I would say, you need to add either storage, or you make sure your disk 1 unloads a lot of used storage, so you have a big buffer. Practically I would just disable the use of a VFS cache. And I also don't see any use for the stats-log flag, when the upload script already arranges that the log shows which files are being uploaded.

Your script seems fine. You can switch logs INFO to DEBUG to maybe catch something. But I'm thinking it's not a Rclone issue, but something with the Unraid system. See: So why don't you put in that manual command in a seperate cron job to execute at start of the system? And if that overlaps with the rclone scripts, add a wait to those scripts.

Are you running the mount script on a continuous cron job? Can you share your specific mount script to see if you maybe configured something wrong? That is a question for the rclone plugin itself. But I don't think that's possible with Unraid because all the plugins are stored on the boot drive. You gave no information about your configurations, folders, disks, sizes, didn't attach the scripts you use. You made it pretty much impossible for us to be of any help.

Yep no issue