wildfire305

I have that same error, too. I don't know what it means, but it hasn't stopped anything from working, yet.

yes, but I used Unraid to create a share called backup first and then I pointed the container at it.

I created a share called Backup and I pointed my docker container to that so I could control access to that folder specifically. The urbackup_tmp_files is in my mnt/user/backup/ directory. That's probably why I haven't noticed it before.

That is probably in your /mnt/user/appdata/urbackup/config folder? It's probably used for temporary files needed by urbackup. Did you specify the location for the backups when installing the docker?

Yes, I use it for 6 windows computers and have tested/restored two of them. Interesting side note: all of the windows computers I run have veracrypt encrypted hard drives as the primary drive that urbackup backs up. When restoring, it is unencrypted until re-encrypting with veracrypt. But the important thing is that it still works!

Original array disk, no. Vibrating disk I was testing, yes

Do I...stop the array switch emulated disk to none, start array, stop array, put original disk back in that slot, start array and it will rebuild from parity

I was testing some 2TB and 3TB non-array disks in the same enclosure as my array disks. Docker and VMs were already disabled prior to testing. One of the non-array test disks started vibrating wildly and kicking udma crc errors left and right. Then, some array disks started building crc errors and one of them became disabled. I stopped all of my processes (badblocks on 5 disks) and tried to powerdown gracefully with the powerdown command. The system hung and could not be ping-ed. I waited 15 minutes and manually powered off everything. I removed the offending drive and promptly put two .22 caliber bullet holes into it for a quick, easy, and satisfying wipe before putting it in the trash. Now the server is restarted, and I'm testing the non-array disks again. The array came up with one disabled/emulated disk. I started it leaving the configuration alone as it said it would do a read test of all the other disks. I figured that would be a good thing and it continued gracefully with no weird format prompts. Questions/Options: Is it possible to get this disabled disk back in the array, or do I have to rebuild it onto itself? Do I have to stop the array to run an XFS filesystem check on the disabled disk? It won't mount read only because I assume the emulated disk is using its uuid. If I were successful at getting it back into the array (possibly using new config), would I need to rebuild/recheck the parity? Ideally, I would like to get this disk mounted somehow, copy it's contents to another disk, and then put it in the array letting the parity rebuild it. Someone helped me before with an XFS command that generated a new UUID (I found my previous post), But I know if I do that, I probably can't bring it back into the array. All the data is backed up...to B2. The disks I'm testing are for my onsite backup pool which I had to destroy the data to retest them. I got some larger disks and freed up slots in the server (12 total) So I could move my backup disks from esata/usb3 enclosures and put them into the main server box. Diagnostics attached for posterity. If y'all have any better paths than what I've thought of, I'm open to suggestions. cvg02-diagnostics-20220319-1817.zip

Unfortunately, no I didn't. I haven't had much free time to dig into it lately - started a new job in January and I'm still learning the ropes. I just tried it again and it did not succeed, but I didn't get an error in the log. I can confirm that the backups absolutely work awesome, even when the client system is using a veracrypt hard drive.

That's where I got to with it. I couldn't understand how it was seeing sr0 as sr0 still when I intentionally tried to map it to a different sr(x) for testing purposes. This docker works excellent with one drive. My server has one built-in (laptop style) dvd burner. I have a usb bluray burner. In order to rip blurays I have to use the makemkv docker or a vm or my w10 laptop. I could never get ripper to ignore sr0 and go for the external. Mapping sr5 (external burner) to sr0 caused it to try to read from both drives simultaneously. I've been dabbling with Linux since 1999 Redhat 5.2, but only really got stuck in firm last year so I'm just chalking it up to my own inexperience. I can follow complex directions, but I need more directions.

@rixAre you in the USA? I have a spare internal sata or external usb optical drive (choose one) I'd donate and ship to you. DM me if interested.

This happened again when I upgraded the firmware on my router this week.

Did you have success with this? I've tried various mappings with docker parameters and I got it to see the other drive, but the directory structure was garbage on output. I tried modding the .sh file and that still was a problem. I've kind of given up on multiple disks and just use something else for bluray (separate drive). @rixI think all of us need more specific instructions on how to get this to work with something other than sr0. Can you post an example of something like sr5/sg12 on the container syntax? I have tried with and without privileged, and I have used --device=/dev/sr5:/dev/sr0 \ --device=/dev/sg12:/dev/sg0 \ and --device=/dev/sr0:/dev/sr5 \ --device=/dev/sg0:/dev/sg12 \ and (I can't remember which one) one of them worked, but the output folder structure that led to the ripped files was all goofed.

I've been having some trouble with my unifi UDM router running out of ram and locking up since the December update. Strangely, if it reboots, sometimes it causes the unraid server to also reboot - dirty. I intentionally rebooted the router this morning because that temporarily solves the lockup issue for a few days. When I rebooted the router unraid kicked some errors into the log and also rebooted. Does this seem like a hardware or software issue? Logs attached, server description in signature. Below are some lines in the syslog that may not show up in diagnostics: cvg02-diagnostics-20220208-1503.zip

Worked like a charm. Thanks! I'm assuming that UUID was assigned to the array and I removed the disk from the array, the system was playing safe not letting the disk back in. Running a diff on it and the new disk 3 now for "peace of mind" comparison.