jmztaylor

Trying in incognito or a browser you don't normally use might be worth a shot too. It seems like a browser caching issue.

you can run diagnostics from the command line and the zip will be on the flash drive

Please post diagnostics.

If I am looking at this right SSH access is turned of in settings->management access

what is your nginx config for overseerr?

To get 80/443 to go to unraid properly, you will have to change the ports unraid gui listens on. This can be done under settings-management access. I have a feeling once that cert expires you are going to have the same issue again. Not completely sure though

If I had to guess, 1980 and 19443 are non standard ports. Since it fails on http-01 test I am assuming it defaults to port 80. Which it cannot connect to. Check the docs of the container you are using for the SSL cert and see if you can pass a different port to use.

Yes RustDeskServer is the hbbs and Relay is the hbbr. I have got this to work without the relay. Using only server and port forwarding port 21116.

Honestly, I just saw this software the other day and started messing with it. The relay I don't know the exact purpose of. Opening 21116 in your firewall will allow external connections and not specifying relay server. So for the settings put your_ip:21116 as the ID server. At least for me it did. Relay might have to do with NAT transversal or something.

I got this in CA now. Both server and relay

This is the support thread for RustDesk Server. I am not a developer of RustDesk. Only made the template for CA. Project Github: https://github.com/rustdesk/rustdesk

Also, FWIW I couldn't get it to run from the docker GUI either. Not sure why

From what I understand from quick read is relay is needed for external connections. I was able to run that command and connect from my phone to computer. But running this should work for the relay docker run --name hbbr -p 21117:21117 -p 21119:21119 -v /mnt/user/appdata/rustserver-hbbr:/root -d --rm rustdesk/rustdesk-server hbbr

This worked for me docker run --name hbbs -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v /mnt/user/appdata/rustserver-hbbs:/root -d --rm rustdesk/rustdesk-server hbbs

I would start with the cable. I have had it happen multiple times the cable won't allow gigabit.

I don't do conversions of files much but in the past I have used Tdarr. Dunno if this will work in your case.

Yeah you just select new cache pool when array is stopped and assign a device to it.

One option is to just use the 1 drive in another cache pool and only use that for data that will be pushed to array quickly. And leave important stuff like VMs and appdata on the 2 drive pool.

Yeah I understand that. I was simply mentioning that Unraid doesn't "stripe" files across disks.

Can you post your diagnostics?

Personally, I have a share called media. Every *arr docker has /mnt/user/media mapped to /media inside the container. My share media is on all disks but Unraid by default spreads this across all disks evenly. So its possible that 1 episode is on disk 1 and the next episode is on disk 2. But it doesn't separate a single file across multiple disks. If you want say tv on a single disk and movies on another, you will have to create those shares separately and in the share settings specify which disk you want them on. If you have parity disk then its possible all disks will be spun up anyways if turbo write is enabled. Using a cache pool pretty much negates the path mappings part of the trash guides also.

try running a btrfs scrub. Also post diagnostics.

First try running a btrfs scrub. Also post diagnostics. Removing docker.img is not destructive. All your app data should be in appdata. If you remove it, then when you start docker again, your containers will be "missing" but going to previous apps in the apps tab, they will all be right there and just have to reinstall them. It will keep all your previous settings.

I don't venture much into different copying techniques but I always use this. Logged into destination server rsync -avzP --progress root@sourceIP:/mnt/user/WHATEVER_SHARE/ /mnt/user/WHATEVER_SHARE/ And any failures can easily be picked back up by running the command again. Once its done I would recommend running again to make sure no data changed on the source server in the meantime.

You can try the manual install to the USB drive