TallMan206

Hi, I have a Dell R720 as Mainserver with UnRAID, and my Backupserver, a SuperMicro with IPMI, also with UnRAID (both running UnRAID 7 beta2). I have a task where the mainserver once per week need to backup to the backupserver. My goal is do use the mainserver and let that connect to the IPMI to boot the server. I tried with backupserver in sleep, but it uses too much power and for the whole week using this power, it's not worth it. Do you know a way to send a signal from the mainserver to the IPMI from the backupserver, making that machine boot?

Hi ich777, I'm sorry, I followed your guide and maybe I did something wrong or I just don't understand well what you are doing, but I could not get it to work. Escpecially the part where you make a testfile local is where I am missing the point. As I wrote, the root/.ssh folder on my target server, seems to be emptied every start, and therefore the source server is not allowed to connect to the target server.

@ich777 the tutorial to keep the authorized_keys after reboot, works! I've rebooted the server and now the mainserver can connect to the backupserver without issues. Luckybackup works right away! Just follow the link, it is still working:

Hi, My appdata is on a separate pool, ssd-pool, where all appdata is stored. Nothing is moving from there to the array/cache. It's an RAID-Z1 pool of three 1TB SSD's. The folder inside of the luckybackup where the rsa is in, is still there (Mainserver) The problem is the backupserver. The autorized keys seems to dissapear after restart I'm following this tutorial now to see if the key finally persist

I'm sorry. After a restart of both servers, LuckyBackup asks again for the openSSH password. Main server: 192.168.100.30: there I putted the rsa inside of luckybackup. Backupserver is the 192.168.100.40 where I copied the rsa key to from my Main server. I think is has to do that the authorized keys are being overwritten at reboot.

I've done it completely different. I made 802.3AD bonding for the 10G NIC's and the 1G NIC's. I anyway, need to set --dns 192.168.100.2 in docker containers that use bond0 with an own IP (Plex and Roonserver have an own IP) so in extra parameters I just put --dns 192.168.100.2 and it works perfectly fine. I hoped to solve this on NIC level, but that is not working.

Hi MAM59, PiHole is NOT running on the UnRAID box (PiHole is running on a Raspberry Pi) so UnRAID should not have a problem while booting to find the DNS.

Hi all, I use 4 NIC's for my Unraid server. 2x 10G and 2x 1G eth0 =10G (static IP, Main/GUI) eth1 =10G (Docker) eth2 =1G (nothing) eth3 =1G (nothing) Only eth0 (main/GUI) has an IP address (192.168.100.30) the rest of the NIC's are not set. I have Pi with Pihole (192.168.100.2) which is my DNS and Dhcp. My ISP router is just the gateway 192.168.100.1. Today I had issues that I never had before, with my Plex docker. I have this since a power fail 2 days ago. It could not claim the server (it dissappeared from my Plex account) , and the server was saying there was an update. It did not work. My docker is set to only to be using eth1 (the 2nd 10G NIC) . My docker advanced setting is: Subnet: 192.168.100.0/24, gateway 192.168.100.1, docker dhcp: not set. This clearly does not hand out DNS to the dockers with an own IP (like plex on 192.168.100.35) How can I make sure my Plex (which I set to use custom: eth1 (docker) to use the DNS? I'll add screenshots.of my settings.

Yes, got everything to work. Thank you so much for the help. Maybe you can add to the text that the rsa key needs to be copied To the backuoserver. I manually copied the rsa key value to my backuoserver (from the main server where luckybackup is running on

SOLVED: run the luckybackup docker with privileged on Hi, thanks for the thread and information. How come I do not have that .ssh folder inside of my luckybackup folder?

I have luckybackup setup following this guide: https://unraid.net/blog/unraid-server-backups-with-luckybackup The RSA on the backupserver side should be here: /root/.ssh/ I configured Luckybackup and everything is working fine. Since my backupserver is not always on, after a restart, Luckybackup was asking for a password, for the tasks that used to work with the id_rsa without problems. What could the restart of the server have caused the id_rsa not to work anymore?

Hi, I pre cleared the disk and no errors. I added it to the array again and everything is fine. Thanks for everything

Hi all, I am wondering if there is a way to properly view Krusader (and other) Docker on a mobile phone. Does VNC allow for mobile phone view or is there a workaround? The page is not sizing to the size of the screen and it's very difficult to do select and do certain tasks within the Krusader window. Thanks.

Hi JorgeB, That works. I have 2 data disks in the system, and disk1 also did not want to start anymore. Now with disk2 in Read Only I can move the data from disk2 to disk1. Perfect! What do you suggest after copying? pre-clear disk2?

The reason for not wanting to copy on disk level, is that I added 3 drives after all the data was on the server already. I want the shares to fill correctly over the drives. If there is no other way, I understand, and I will do it on disk level. Thanks for the answer.

Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sdd Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sde Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sdb Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sdf Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sdc Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/nvme1n1 Sep 3 11:47:56 UnRAID emhttpd: read SMART /dev/sda Sep 3 11:47:56 UnRAID SysDrivers: SysDrivers Build Starting Sep 3 11:48:06 UnRAID Parity Check Tuning: Unclean shutdown detected Sep 3 11:48:06 UnRAID Parity Check Tuning: Send notification: Unclean shutdown detected: See **Troubleshooting** section of the Unraid OS Manual in the online documetaion to get guidance on resolving this (type=alert link=) Sep 3 11:48:06 UnRAID kernel: mdcmd (31): set md_num_stripes 1280 Sep 3 11:48:06 UnRAID kernel: mdcmd (32): set md_queue_limit 80 Sep 3 11:48:06 UnRAID kernel: mdcmd (33): set md_sync_limit 5 Sep 3 11:48:06 UnRAID kernel: mdcmd (34): set md_write_method 1 Sep 3 11:48:06 UnRAID kernel: mdcmd (35): start DISABLE_DISK Sep 3 11:48:06 UnRAID kernel: unraid: allocating 20870K for 1280 stripes (4 disks) Sep 3 11:48:06 UnRAID kernel: md1p1: running, size: 19531825100 blocks Sep 3 11:48:06 UnRAID kernel: md2p1: running, size: 15625879500 blocks Sep 3 11:48:07 UnRAID emhttpd: shcmd (58): udevadm settle Sep 3 11:48:07 UnRAID emhttpd: Opening encrypted volumes... Sep 3 11:48:07 UnRAID emhttpd: shcmd (59): touch /boot/config/forcesync Sep 3 11:48:08 UnRAID emhttpd: Mounting disks... Sep 3 11:48:08 UnRAID emhttpd: mounting /mnt/disk1 Sep 3 11:48:08 UnRAID emhttpd: shcmd (60): mkdir -p /mnt/disk1 Sep 3 11:48:08 UnRAID emhttpd: /usr/sbin/zpool import -f -d /dev/md1p1 2>&1 Sep 3 11:48:11 UnRAID emhttpd: pool: disk1 Sep 3 11:48:11 UnRAID emhttpd: id: 4076012607772953184 Sep 3 11:48:11 UnRAID emhttpd: shcmd (61): /usr/sbin/zpool import -f -N -o autoexpand=on -d /dev/md1p1 4076012607772953184 disk1 Sep 3 11:48:16 UnRAID emhttpd: shcmd (62): /usr/sbin/zpool online -e disk1 /dev/md1p1 Sep 3 11:48:17 UnRAID emhttpd: /usr/sbin/zpool status -PL disk1 2>&1 Sep 3 11:48:17 UnRAID emhttpd: pool: disk1 Sep 3 11:48:17 UnRAID emhttpd: state: ONLINE Sep 3 11:48:17 UnRAID emhttpd: scan: scrub repaired 0B in 12:11:54 with 0 errors on Mon Sep 2 00:12:08 2024 Sep 3 11:48:17 UnRAID emhttpd: config: Sep 3 11:48:17 UnRAID emhttpd: #011NAME STATE READ WRITE CKSUM Sep 3 11:48:17 UnRAID emhttpd: #011disk1 ONLINE 0 0 0 Sep 3 11:48:17 UnRAID emhttpd: #011 /dev/md1p1 ONLINE 0 0 0 Sep 3 11:48:17 UnRAID emhttpd: errors: No known data errors Sep 3 11:48:17 UnRAID emhttpd: shcmd (63): /usr/sbin/zfs set mountpoint=/mnt/disk1 disk1 Sep 3 11:48:17 UnRAID emhttpd: shcmd (64): /usr/sbin/zfs set atime=off disk1 Sep 3 11:48:17 UnRAID emhttpd: shcmd (65): /usr/sbin/zfs mount disk1 Sep 3 11:48:17 UnRAID emhttpd: shcmd (66): /usr/sbin/zpool set autotrim=off disk1 Sep 3 11:48:17 UnRAID emhttpd: shcmd (67): /usr/sbin/zfs set compression=on disk1 Sep 3 11:48:18 UnRAID emhttpd: mounting /mnt/disk2 Sep 3 11:48:18 UnRAID emhttpd: shcmd (68): mkdir -p /mnt/disk2 Sep 3 11:48:18 UnRAID emhttpd: /usr/sbin/zpool import -f -d /dev/md2p1 2>&1 Sep 3 11:48:21 UnRAID emhttpd: pool: disk2 Sep 3 11:48:21 UnRAID emhttpd: id: 570875432498759471 Sep 3 11:48:21 UnRAID emhttpd: shcmd (69): /usr/sbin/zpool import -f -N -o autoexpand=on -d /dev/md2p1 570875432498759471 disk2 Sep 3 11:48:25 UnRAID kernel: VERIFY3(0 == dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, &numbufs, &dbp)) failed (0 == 5) Sep 3 11:48:25 UnRAID kernel: PANIC at dmu.c:1123:dmu_write() Sep 3 11:48:25 UnRAID kernel: Showing stack for process 17758 Sep 3 11:48:25 UnRAID kernel: CPU: 26 PID: 17758 Comm: txg_sync Tainted: P O 6.1.106-Unraid #1 Sep 3 11:48:25 UnRAID kernel: Hardware name: Dell Inc. PowerEdge R720/0W7JN5, BIOS 2.9.0 12/06/2019 Sep 3 11:48:25 UnRAID kernel: Call Trace: Sep 3 11:48:25 UnRAID kernel: <TASK> Sep 3 11:48:25 UnRAID kernel: dump_stack_lvl+0x44/0x5c Sep 3 11:48:25 UnRAID kernel: spl_panic+0xd0/0xe8 [spl] Sep 3 11:48:25 UnRAID kernel: ? dmu_buf_hold_array_by_dnode+0x279/0x41c [zfs] Sep 3 11:48:25 UnRAID kernel: ? preempt_latency_start+0x2b/0x46 Sep 3 11:48:25 UnRAID kernel: ? _raw_spin_lock+0x13/0x1c Sep 3 11:48:25 UnRAID kernel: ? _raw_spin_unlock+0x14/0x29 Sep 3 11:48:25 UnRAID kernel: ? dnode_rele_and_unlock+0x67/0xb6 [zfs] Sep 3 11:48:25 UnRAID kernel: ? dmu_buf_hold_array.constprop.0+0x7b/0xa2 [zfs] Sep 3 11:48:25 UnRAID kernel: ? dmu_buf_hold_array_by_dnode+0x24d/0x41c [zfs] Sep 3 11:48:25 UnRAID kernel: dmu_write+0x77/0xf0 [zfs] Sep 3 11:48:25 UnRAID kernel: ? _raw_spin_lock+0x13/0x1c Sep 3 11:48:25 UnRAID kernel: space_map_write+0x19c/0x605 [zfs] Sep 3 11:48:25 UnRAID kernel: ? dmu_object_size_from_db+0x22/0x6d [zfs] Sep 3 11:48:25 UnRAID kernel: ? space_map_open_impl+0x48/0x76 [zfs] Sep 3 11:48:25 UnRAID kernel: metaslab_flush+0x1ba/0x326 [zfs] Sep 3 11:48:25 UnRAID kernel: ? spa_generate_syncing_log_sm+0x1f4/0x21a [zfs] Sep 3 11:48:25 UnRAID kernel: spa_flush_metaslabs+0x2bf/0x334 [zfs] Sep 3 11:48:25 UnRAID kernel: spa_sync+0x7c9/0xd12 [zfs] Sep 3 11:48:25 UnRAID kernel: txg_sync_thread+0x1f3/0x375 [zfs] Sep 3 11:48:25 UnRAID kernel: ? __kmem_cache_free+0x6a/0xf5 Sep 3 11:48:25 UnRAID kernel: ? txg_fini+0x1c2/0x1c2 [zfs] Sep 3 11:48:25 UnRAID kernel: ? __thread_exit+0x13/0x13 [spl] Sep 3 11:48:25 UnRAID kernel: thread_generic_wrapper+0x5a/0x65 [spl] Sep 3 11:48:25 UnRAID kernel: kthread+0xe7/0xef Sep 3 11:48:25 UnRAID kernel: ? kthread_complete_and_exit+0x1b/0x1b Sep 3 11:48:25 UnRAID kernel: ret_from_fork+0x22/0x30 Sep 3 11:48:25 UnRAID kernel: </TASK> Sep 3 11:48:26 UnRAID SysDrivers: SysDrivers Build Complete Sep 3 11:48:38 UnRAID SysDrivers: SysDrivers Build Complete Sep 3 11:51:04 UnRAID nginx: 2024/09/03 11:51:04 [error] 9887#9887: *40 upstream timed out (110: Connection timed out) while reading upstream, client: 192.168.100.160, server: , request: "POST /update.htm HTTP/1.1", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "192.168.100.30", referrer: "http://192.168.100.30/Main" Sep 3 11:51:04 UnRAID nginx: 2024/09/03 11:51:04 [alert] 9887#9887: *148 open socket #13 left in connection 7 Sep 3 11:51:04 UnRAID nginx: 2024/09/03 11:51:04 [alert] 9887#9887: *120 open socket #4 left in connection 10 Sep 3 11:51:04 UnRAID nginx: 2024/09/03 11:51:04 [alert] 9887#9887: *103 open socket #28 left in connection 12 Sep 3 11:51:04 UnRAID nginx: 2024/09/03 11:51:04 [alert] 9887#9887: aborting

Hi all, I am searching and reading a lot on how to move data between shares within the same server. I am currently moving a lot of data using MC, and this does take forever, while I read a lot about that I could be instant. How do I do this? I prefer not to do it on disk level. Thanks.

Hi JorgeB, I have the logs from a in Maintenance started array, because I cannot start the array. unraid-diagnostics-20240903-1039.zip

Hi all, My system does not start up properly anymore after a reboot after I found that a scrub on disk2 did not want to finish. The array hangs on mounting disk2. I also cannot download the logs, because it is trying to get the pool status which is not working. Is threre a CLI command that I can use? Can you help me find the issue?

I had a drive scrubbing finding errors: pool: disk2 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A scan: scrub in progress since Mon Sep 2 12:00:23 2024 5.06T scanned at 0B/s, 5.04T issued at 138M/s, 5.06T total 4.47M repaired, 99.71% done, 00:01:50 to go config: NAME STATE READ WRITE CKSUM disk2 ONLINE 0 0 0 md2p1 ONLINE 0 0 11.3K (repairing) errors: Permanent errors have been detected in the following files: <metadata>:<0x701> <metadata>:<0x801> <metadata>:<0xf01> <metadata>:<0x702> <metadata>:<0xf02> <metadata>:<0x3> <metadata>:<0x103> <metadata>:<0x303> <metadata>:<0x903> <metadata>:<0xb03> <metadata>:<0x4> <metadata>:<0x304> <metadata>:<0x504> <metadata>:<0x604> <metadata>:<0x704> <metadata>:<0x904> <metadata>:<0xa04> <metadata>:<0xc04> <metadata>:<0xe04> <metadata>:<0x5> <metadata>:<0x605> <metadata>:<0x705> <metadata>:<0xa05> <metadata>:<0xb05> <metadata>:<0xc05> <metadata>:<0xe05> <metadata>:<0xf05> <metadata>:<0x6> <metadata>:<0x106> <metadata>:<0x806> <metadata>:<0xf06> <metadata>:<0x7> <metadata>:<0x207> <metadata>:<0x607> <metadata>:<0x907> <metadata>:<0x8> <metadata>:<0x108> <metadata>:<0x208> <metadata>:<0x408> <metadata>:<0x508> <metadata>:<0x608> <metadata>:<0x908> <metadata>:<0x9> <metadata>:<0x109> <metadata>:<0x409> <metadata>:<0x509> <metadata>:<0xa09> <metadata>:<0xd09> <metadata>:<0xa> <metadata>:<0x10a> <metadata>:<0x30a> <metadata>:<0x80a> <metadata>:<0xa0a> <metadata>:<0xb> <metadata>:<0x10b> <metadata>:<0x50b> <metadata>:<0x60b> <metadata>:<0x80b> <metadata>:<0x10c> <metadata>:<0x40c> <metadata>:<0x60c> <metadata>:<0xa0c> <metadata>:<0xb0c> <metadata>:<0xc0c> <metadata>:<0x10d> <metadata>:<0xa0d> <metadata>:<0xb0d> <metadata>:<0xc0d> <metadata>:<0x30e> <metadata>:<0x50e> <metadata>:<0x80e> <metadata>:<0x90e> <metadata>:<0xf> <metadata>:<0x20f> <metadata>:<0x30f> <metadata>:<0x80f> <metadata>:<0xb0f> <metadata>:<0xc0f> <metadata>:<0x10> <metadata>:<0x410> <metadata>:<0x510> <metadata>:<0x610> <metadata>:<0x910> <metadata>:<0xc10> <metadata>:<0x311> <metadata>:<0x411> <metadata>:<0x911> <metadata>:<0x12> <metadata>:<0x312> <metadata>:<0x512> <metadata>:<0x712> <metadata>:<0xa12> <metadata>:<0xb12> <metadata>:<0xc12> <metadata>:<0xd12> <metadata>:<0x13> <metadata>:<0x213> <metadata>:<0x713> <metadata>:<0xa13> <metadata>:<0xc13> <metadata>:<0x114> <metadata>:<0x314> <metadata>:<0xd15> <metadata>:<0x16> <metadata>:<0x316> <metadata>:<0x916> <metadata>:<0xb16> <metadata>:<0x117> <metadata>:<0x217> <metadata>:<0x118> <metadata>:<0x218> <metadata>:<0x318> <metadata>:<0xb18> <metadata>:<0x319> <metadata>:<0x31a> <metadata>:<0x31b> <metadata>:<0xf1b> <metadata>:<0x31c> <metadata>:<0xb1c> <metadata>:<0xf1c> <metadata>:<0x11e> <metadata>:<0x121> <metadata>:<0xc22> <metadata>:<0xe22> <metadata>:<0xc23> <metadata>:<0x125> <metadata>:<0x527> <metadata>:<0xe27> <metadata>:<0x528> <metadata>:<0xa29> <metadata>:<0x22a> <metadata>:<0xc2a> <metadata>:<0x22b> <metadata>:<0x42b> <metadata>:<0x22d> <metadata>:<0x22e> <metadata>:<0x72f> <metadata>:<0x730> <metadata>:<0x930> <metadata>:<0x931> <metadata>:<0xc31> <metadata>:<0x734> <metadata>:<0x35> <metadata>:<0x735> <metadata>:<0xc35> <metadata>:<0x936> <metadata>:<0x237> <metadata>:<0xc38> <metadata>:<0x239> <metadata>:<0xc39> <metadata>:<0xd39> <metadata>:<0x23a> <metadata>:<0x53a> <metadata>:<0xa3a> <metadata>:<0xd3a> <metadata>:<0x53b> <metadata>:<0x3c> <metadata>:<0xa3c> <metadata>:<0xb3c> <metadata>:<0xc3c> <metadata>:<0xb3d> <metadata>:<0x640> <metadata>:<0x641> <metadata>:<0x42> <metadata>:<0x43> <metadata>:<0x143> <metadata>:<0x144> <metadata>:<0x846> <metadata>:<0x847> <metadata>:<0x84a> <metadata>:<0x84d> <metadata>:<0x5f> <metadata>:<0x62> <metadata>:<0x69> <metadata>:<0x6d> <metadata>:<0x6e> <metadata>:<0x70> <metadata>:<0x71> <metadata>:<0x73> <metadata>:<0x76> <metadata>:<0x77> <metadata>:<0x881> <metadata>:<0xa81> <metadata>:<0xc81> <metadata>:<0xe81> <metadata>:<0x382> <metadata>:<0x682> <metadata>:<0x882> <metadata>:<0xa82> <metadata>:<0xc82> <metadata>:<0xe82> <metadata>:<0xf82> <metadata>:<0x283> <metadata>:<0x383> <metadata>:<0x683> <metadata>:<0x983> <metadata>:<0xf83> <metadata>:<0x884> <metadata>:<0x984> <metadata>:<0x185> <metadata>:<0x685> <metadata>:<0xc85> <metadata>:<0xd85> <metadata>:<0xe85> <metadata>:<0xf85> <metadata>:<0x386> <metadata>:<0x686> <metadata>:<0xa86> <metadata>:<0xe86> <metadata>:<0xf86> <metadata>:<0x87> <metadata>:<0x787> <metadata>:<0x987> <metadata>:<0xa87> <metadata>:<0xd87> <metadata>:<0x88> <metadata>:<0x288> <metadata>:<0x988> <metadata>:<0xb88> <metadata>:<0xd88> <metadata>:<0xf88> <metadata>:<0x289> <metadata>:<0x789> <metadata>:<0xc89> <metadata>:<0xe89> <metadata>:<0xf89> <metadata>:<0x8a> <metadata>:<0x48a> <metadata>:<0x58a> <metadata>:<0x68a> <metadata>:<0x78a> <metadata>:<0xa8a> <metadata>:<0xb8a> <metadata>:<0xd8a> <metadata>:<0x28b> <metadata>:<0x48b> <metadata>:<0x58b> <metadata>:<0xa8b> <metadata>:<0xb8b> <metadata>:<0xc8b> <metadata>:<0xe8b> <metadata>:<0xf8b> <metadata>:<0x28c> <metadata>:<0x38c> <metadata>:<0xe8c> <metadata>:<0x68d> <metadata>:<0xa8d> <metadata>:<0xd8d> <metadata>:<0xf8d> <metadata>:<0x68e> <metadata>:<0x78e> <metadata>:<0xa8e> <metadata>:<0xd8e> <metadata>:<0xb8f> <metadata>:<0xc8f> <metadata>:<0xe8f> <metadata>:<0x190> <metadata>:<0x590> <metadata>:<0xb90> <metadata>:<0xc90> <metadata>:<0xe90> <metadata>:<0x191> <metadata>:<0x291> <metadata>:<0x991> <metadata>:<0xd91> <metadata>:<0x92> <metadata>:<0x292> <metadata>:<0x392> <metadata>:<0x692> <metadata>:<0xd92> <metadata>:<0xe92> <metadata>:<0xf92> <metadata>:<0x93> <metadata>:<0x693> <metadata>:<0x993> <metadata>:<0xc93> <metadata>:<0xe93> <metadata>:<0xf93> <metadata>:<0x394> <metadata>:<0x494> <metadata>:<0x95> <metadata>:<0x395> <metadata>:<0x695> <metadata>:<0x96> <metadata>:<0x196> <metadata>:<0x296> <metadata>:<0x197> <metadata>:<0x297> <metadata>:<0x897> <metadata>:<0xd97> <metadata>:<0xe97> <metadata>:<0xd98> <metadata>:<0x99> <metadata>:<0x599> <metadata>:<0x59a> <metadata>:<0x29c> <metadata>:<0xe9c> <metadata>:<0x4a1> <metadata>:<0x4a3> <metadata>:<0x4a6> <metadata>:<0x8a6> <metadata>:<0x2a8> <metadata>:<0x2a9> <metadata>:<0xda9> <metadata>:<0xaa> <metadata>:<0xdaa> <metadata>:<0x1ab> <metadata>:<0xaab> <metadata>:<0x1ac> <metadata>:<0xaac> <metadata>:<0xbac> <metadata>:<0x3ad> <metadata>:<0x3ae> <metadata>:<0xaae> <metadata>:<0x3af> <metadata>:<0xaaf> <metadata>:<0xbb0> <metadata>:<0xdb0> <metadata>:<0x1b1> <metadata>:<0x9b1> <metadata>:<0xdb1> <metadata>:<0xeb1> <metadata>:<0x7b2> <metadata>:<0xeb2> <metadata>:<0x2b3> <metadata>:<0x9b3> <metadata>:<0xdb3> <metadata>:<0xb4> <metadata>:<0xeb4> <metadata>:<0x9b5> <metadata>:<0xb6> <metadata>:<0x9b6> <metadata>:<0xb7> <metadata>:<0x3b7> <metadata>:<0x7b7> <metadata>:<0x3b8> <metadata>:<0x7b8> <metadata>:<0xab8> <metadata>:<0xfb8> <metadata>:<0x2b9> <metadata>:<0xfb9> <metadata>:<0x9ba> <metadata>:<0xeba> <metadata>:<0xbb> <metadata>:<0x9bb> <metadata>:<0xebb> <metadata>:<0xbc> <metadata>:<0xbbc> <metadata>:<0x2bd> <metadata>:<0xfbd> <metadata>:<0x2be> <metadata>:<0xbf> <metadata>:<0xc0> <metadata>:<0x6c0> <metadata>:<0xfc0> <metadata>:<0x6c1> <metadata>:<0xfc1> <metadata>:<0x6c3> <metadata>:<0xec3> <metadata>:<0x6c4> <metadata>:<0xc5> <metadata>:<0xc6> <metadata>:<0x6c7> <metadata>:<0x5c8> <metadata>:<0x5c9> <metadata>:<0x5cc> <metadata>:<0x5cd> How can I find the files 'behind' this metadata? I have no clue which files to restore. Thanks.

Hi, can I empty the /boot/config/ssh folder without issues, or do I break things then? What is save to remove inside of that folder? Thanks.

If I try to run the user script, is ask me for a root password (just as in the terminal when setting up the ssh copy For example: Example 2 This command copies files from SiteB to SiteA, both have matching share names rsync -avz -e "ssh -i /root/.ssh/siteA-rsync-key" [email protected]:/mnt/user/homework/isos/ /mnt/user/homework/isos/ this requires me to type in a root password (from my main server) I did NOT use a password while setting up site A Setting up Site A Let's start by opening an Unraid Terminal window. In the top right corner of the Unraid WebUI press the Icon that looks like this >_ Now, we need to execute a few commands. First, we need to generate a public/private key pair to allow an SSH connection to work without a password and manual intervention. To do this simply do the following command on Site A. ssh-keygen -t rsa -b 2048 -f /root/.ssh/siteA-rsync-key You will be prompted to “Enter a Passphrase”. Hit the ‘Enter’ key twice. Deep breath. Should I use a password?

Also don't forget to set in user preferences, the items per page, to a higher number. The arrows for the next and previous pages, are also low visible so easy to look over.

Hi @JorgeB can a 'bad' array drive cause the server to hang, throw HTTP error 500's and even block the server from shutting down? I see the drive is blinking all the time, but the server does not react to anything else. I needed to shut down through CLI, and it is still hanging in this process. The reason for this question: I was backing up the main server to the backupserver, which was writing to a 8TB HDD, and now starts writing on the 4TB HDD that you already noticed earlier to give issues. Since the data is now written to the 4TB HDD, the server is misbehaving again, while it was running perfectly fine when it was still writing the 8TB HDD.

Does this app keep the permissions intact after restore? In my case: Immich with the PostgreSQL_Immich Database. The DB has 999 as user, I backup Immich and the DB, and will the DB still work after restore, keeping the permissions intact?