Spatial Disorder

Thanks@Hoopster! I would have never figured that out. My last part for a long overdue upgrade came in a couple days ago, had everything ready to go todayx, then no boot. Renaming the folder fixed it and all is good. Thanks!

Also seeing this error...rolled back to `3.7.0-1-01` and all is well...

Same here...pulled down the new test update and acquired port right away on the first attempt. Everything is looking good so far.

My external ip is showing accurately in the bottom right. I didn't pay attention when I first connected...so I'm not sure if it refreshes at some interval or not?

Setup next-gen connected to Toronto without issue, though it did take about 40 minutes before finally getting a port. Speeds seem to be as good or possibly better, but I haven't tested much to confirm. As always, thanks @binhex for the top-notch support and keeping this updated!

Wow...0.5PB...that's pretty impressive. Any concerns with monthly bandwidth utilization? No issues from your ISP? I've also been using duplicati for the last few years, been very happy with it overall. Do you do anything different with your offsite mount to ensure you could recover in the event of...say an accidental deletion?

Thanks, that makes sense. The more I think about it the more I'm leaning toward going all in on this in order to simplify everything. Right now I have a mix of data local and in gdrive. I'm with you on being lazy...I work in IT and the older I get the less I want to mess with certain aspects of it...just want reliability. I really only have one share that would even be a concern...and now that I think about it...it should probably live in an encrypted vault...

First @DZMM , thanks for sharing this and thank to everyone that has contributed to make it better. I've been using for a few months now with mostly no issues (had that odd orphaned image issue a while back that a few of us had with mergerfs). That was really the only hiccup. I'm really considering moving everything offsite... As for hardlinks, this is timely, as I've finally decided to get around to making hardlinks and get seeding to work properly. When i originally setup things I had: /mnt/user/media <with sub directories for tv/movies/music/audiobooks /mnt/user/downloads <with sub directories for complete/incomplete Your script came along and I then added: /mnt/user/gdrive_local /mnt/user/gdrive_mergerfs /mnt/user/gdrive_rclone I know just mapping all containers to /mnt/user would solve this...but I'm a little apprehensive about giving all the necessary applications read/write to the entire array. I don't have any of this data going to cache...so is there anything stopping me, or a good reason not to, stuff everything into /mnt/user/media and then map everything to that?

@DZMM and @teh0wner Thanks for the help, I'm back up and running and have moved to the latest working scripts with no issues the last 24 hours. I'm fairly certain the new scripts were failing due to the latest mergerfs not getting pulled. Just for good measure I: Deleted all shares (local, rclone mount, mergerfs mount) Ran docker rmi [imageID] to get rid of the old mergerfs image After some reading up on rclone vs rclone-beta, I reverted back to rclone (I don't think this was the issue, but for this purpose would rather be on a stable release and I see nothing that needs the new stuff in the beta release). I'm sure it's fine either way. Pulled latest github scripts and modified variables for my setup Clean reboot for good measure Thanks for all the work putting this together 🤘

@DZMM I blew away all shares and appdata, rebooted, then manually ran mkdir -p /mnt/user/appdata/other/rclone/mergerfs docker run -v /mnt/user/appdata/other/rclone/mergerfs:/build --rm trapexit/mergerfs-static-build mv /mnt/user/appdata/other/rclone/mergerfs/mergerfs /bin I then ran the latest gdrive_rclone_mount script and it runs successfully (shown below). As soon as I even try to list contents of mount_mergerfs the terminal freezes and it pegs a core on the CPU and never responds. I'm not sure what to try... Script location: /tmp/user.scripts/tmpScripts/gdrive_mount/script Note that closing this window will abort the execution of this script 01.03.2020 12:50:26 INFO: *** Starting mount of remote gdrive_media_vfs 01.03.2020 12:50:26 INFO: Checking if this script is already running. 01.03.2020 12:50:26 INFO: Script not running - proceeding. 01.03.2020 12:50:26 INFO: Mount not running. Will now mount gdrive_media_vfs remote. 01.03.2020 12:50:26 INFO: Recreating mountcheck file for gdrive_media_vfs remote. 2020/03/01 12:50:26 DEBUG : rclone: Version "v1.51.0-076-g38a4d50e-beta" starting with parameters ["rcloneorig" "--config" "/boot/config/plugins/rclone-beta/.rclone.conf" "copy" "mountcheck" "gdrive_media_vfs:" "-vv" "--no-traverse"] 2020/03/01 12:50:26 DEBUG : Using config file from "/boot/config/plugins/rclone-beta/.rclone.conf" 2020/03/01 12:50:27 DEBUG : mountcheck: Modification times differ by -12h40m10.128729289s: 2020-03-01 12:50:26.567729289 -0500 EST, 2020-03-01 05:10:16.439 +0000 UTC 2020/03/01 12:50:29 INFO : mountcheck: Copied (replaced existing) 2020/03/01 12:50:29 INFO : Transferred: 32 / 32 Bytes, 100%, 20 Bytes/s, ETA 0s Transferred: 1 / 1, 100% Elapsed time: 1.5s 2020/03/01 12:50:29 DEBUG : 7 go routines active 01.03.2020 12:50:29 INFO: *** Creating mount for remote gdrive_media_vfs 01.03.2020 12:50:29 INFO: sleeping for 5 seconds 01.03.2020 12:50:34 INFO: continuing... 01.03.2020 12:50:34 INFO: Successful mount of gdrive_media_vfs mount. 01.03.2020 12:50:34 INFO: Mergerfs already installed, proceeding to create mergerfs mount 01.03.2020 12:50:34 INFO: Creating gdrive_media_vfs mergerfs mount. 01.03.2020 12:50:34 INFO: Checking if gdrive_media_vfs mergerfs mount created. 01.03.2020 12:50:34 INFO: Check successful, gdrive_media_vfs mergerfs mount created. 01.03.2020 12:50:34 INFO: Starting dockers. "docker start" requires at least 1 argument. See 'docker start --help'. Usage: docker start [OPTIONS] CONTAINER [CONTAINER...] Start one or more stopped containers 01.03.2020 12:50:34 INFO: Script complete

I'm also seeing an issue with mergerfs hanging @teh0wner. I was doing some maintenance last night and decided to update to the latest version of this script and could not access the mergerfs mount. It would peg a single core on the CPU and just hang. I reverted back to the older script, that had previously been working for a month+, and seeing the same issue. I blew away all directories (local, mount_rclone, mount_mergerfs, appdata/other) and clean reboot with same issue. Looking at the last few posts I'm wondering if it isn't something that changed with trapexit/mergerfs-static-build

Great work. Upgrade went smooth.

I had the same issues as @rbroberts when updating the container a few months back. Everything would be working fine, then break after updating the container. After the first time, I blew everything away, did a clean setup, worked great until another update and it happened again, so I bailed on using it. I was mostly just screwing around with it and wasn't really interested in troubleshooting it. I din't keep any logs, so this is probably useless, other than stating I've also seen this same issue.

I don't know that I need it....but what's the root password? I tried root with password 5iveL!fe and it doesn't seem work. Otherwise, I was able to setup and account and it's been working great. I'm an idiot...it's the first thing I setup after hitting the web gui I realized this after doing a clean install. Unfortunately after testing out for a week or two, I got a 502 error out of know where...never could get it to recover. Wasn't worth the effort, so I just re-installed.

Experienced the same thing this morning after the update. Changed gateway to CA Toronto (ca-toronto.privateinternetaccess.com) and all is well.