Thel1988

Members
  • Posts

    15
  • Joined

  • Last visited

Thel1988's Achievements

Noob

Noob (1/14)

1

Reputation

  1. Yes, the UMASK was set to 002 for that specific docker container I couldn't get working. But yes I think Yes I actually think that this is the cause of the issue, that it is actually never been working as intended.
  2. I seem to have the same issue with 6.10 RC2, tried with the above settings. Really weird. UPDATE: Seems the UMASK needed to be corrected on the docker containers as well.
  3. You can look at hetzner and their server auction, they have some pretty good server for around 30-40€ depending of your location ofcause. And they have servers with HDDs.
  4. This is really nice, i'm currently playing around with this, and this will simplify my setup, can you share in which order you run the custom scripts, like in what priority, and which schedule? Also it would awesome to have some short readme in github, to help with the setup.
  5. I get the same issue, where I need to kill of rclone and reconnect the mount points, rerunning the script does nothing to fix that error.
  6. Have you checked which version of rclone you have installed? You need at least 1.51 to support the order by function.
  7. Interresting way of doing it by date actually, if you share a bit more details on how you do it, that would be nice isn't there a limitation on how much you can move between drives?
  8. Yeap I have been cloning and merged it with my settings, and it is like this. But it kind of make sense from my side: This is the output of my find command (before cut) /mnt/user/appdata/other/rclone/Upload_user1_vfs/counter_2 Correct me if i'm wrong, I have been reading into how the CUT command is working: cut -d"_" -f4 the -d"_" will tell it what delimter it should, and after that which field it should output, in my example above. field1: /mnt/user/appdata/other/rclone/Upload field2: user1 field3:vfs/counter and then field4: 2 So in my example it will be -f4
  9. Thanks this works great, I still need to adjust the cut command to 4 as it is my fourth field, but really cool on the simplification of the scripts: find /mnt/user/appdata/other/rclone/upload_user1_vfs/ -name 'counter_*' | cut -d"_" -f3 Give this output: vfs/counter Changing the cut command to use field number 4 it outputs it correctly: find /mnt/user/appdata/other/rclone/upload_user1_vfs/ -name 'counter_*' | cut -d"_" -f4 2
  10. @DZMM Good additions to your scripts Got one question though about the mkdir -p command in line 60, i can't find anywhere else, where the $RcloneUploadRemoteName folder is created in the upload script, is it me who is reading it wrong? As it seems the $RcloneUploadRemoteName subfolder is being Touched.
  11. I just wanna say, Thanks @DZMM for the new versions of the scripts combined with the multiple upload accounts, it is just making my life so much easier Just a little tidbit, if you use the multiple upload feature, and use more than 1 "_" in your remote name, like i did, change the CUT command from field 3 to field 4 from: find /mnt/user/appdata/other/rclone/name_media_vfs/ -name 'counter_*' | cut -d"_" -f3 to: find /mnt/user/appdata/other/rclone/name_media_vfs/ -name 'counter_*' | cut -d"_" -f4 If you don't do the above, it will not rotate the accounts
  12. Okay I got it to work I needed to delete the extra /media/downloads in the path mappings and then it works Anways thanks for your help @DZMM you do a fantastic job on these scripts
  13. Okay good Point. I have changed to this: Radarr: /media/downloads <-> /mnt/user/mount_unionfs/google_vfs/downloads/ /media <-> /mnt/user/mount_unionfs/google_vfs/ for sabnzb: /media/downloads <-> /mnt/user/mount_unionfs/google_vfs/downloads/ It is still awfully slow, does the cache settings on the local share have anything to say on this?
  14. I have migrated from the unionFS to MergerFS, but it seems I have very very slow move speed from like sonarr or radarr to my Media folder. (Taking 3 minutes to move 4 GB file), so i think it is somehow Copying instead of Moving. Also if I do the same thing from within the Sonarr docker it also takes this long to MOVE a file. I'm using the following MergerFS command: mergerfs /mnt/user/local/google_vfs:/mnt/user/mount_rclone/google_vfs=RO:/mnt/user/media=RO /mnt/user/mount_unionfs/google_vfs -o rw,async_read=false,use_ino,allow_other,func.getattr=newest,category.action=all,category.create=ff,cache.files=partial,dropcacheonclose=true It seems sonarr is really taking long time to move from the /data to /media in the Sonarr docker. Path mappings: /data <-> /mnt/user/mount_unionfs/google_vfs/downloads/ /media <-> /mnt/user/mount_unionfs/google_vfs/ I can see that the SSD cache is hard at work when it is moving files.