JonathanM

your sonarr has /data mapped to /mnt/user/data/, but bazarr has /media mapped to /mnt/user/data both sides of the mapping must match, not just the host side. you may have to delete the current mappings and remake them, as well as point bazarr to /data instead of /media inside the application. I'm not familiar with bazarr so I can't tell you specifically what to do.

They are stored inside the docker.img file. You can delete and recreate it empty, and all layers will be downloaded fresh. If you have any custom networks, make sure you recreate those before you pull any containers that reference them.

If that was a response to me, that is exactly what I did, I had binhex-mineos that produced the archive, I put it in the import folder and created a server based on that archive. The issue is that binhex's container ran mineos with Unraid type generic permissions, but this official container sets up a mc user that owns all the files. When trying to read the world file for mapping with another container, permission is denied. This mineos sets permissions that make the files difficult to work with outside of the container.

Then it definitely did NOT write zeroes to the entire capacity of the drive while updating parity to keep it in sync. That would typically take at least as long or longer than a full parity check, probably a day or so under ideal conditions. If the array was still in use while it was writing, I wouldn't be surprised if it took several days. Empty != clear. Empty means the table of contents has no pointers to files or folders. Deleted files still exist as ones and zeroes across the drive, you can only remove the drive without rebuilding parity if the entire drive has had zeroes written to it. It definitely did not, based on the length of time it took, as well as... The time it takes to do a correcting parity check is way longer than the time it takes to do a build from scratch, so if it's less than a quarter completed by now, you should probably stop the check, unassign the parity drive, start the array, stop the array, assign the parity drive, and let it rebuild, followed by a correcting check that should have zero errors. If it's almost done with the correcting check I'd let it finish, then follow it up with another correcting check to make sure you have zero parity errors remaining. That script works for some, fails miserably for others. This is the second time in the last week or so I've seen the same thing reported. There is a reason it's only in the legacy documentation and hasn't been moved to the current docs. When first authored it worked well, but something in newer configs seems to be causing issues. Keep in mind that valid parity can recover a failed drive as long as all the rest of the data drives are able to be read perfectly, but it doesn't protect your data from user error or corruption. You must still keep a second copy of data that you feel is irreplaceable somewhere other than the server. You probably don't have to back up the entire content of your server, but if it can't be replaced from another source, either your backups or the internet in general, it's not protected. Unraid or any RAID only covers a subset of things that can eat your data.

Can you reproduce this on a different machine or a fresh install of windows?

This isn't a USB issue, you must disable secure boot.

How big was the drive? How many days did the script take to complete?

Update it, but yes. Technically Unraid reinstalls itself every boot, it installs into RAM and runs from there. The USB stick holds the OS archives that get extracted into RAM, as well as any configuration changes to the OS itself. To update Unraid, you overwrite the bz* and other files in the root of the stick.

Use this to upgrade then register. https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Just use your already licensed USB stick. Make a full backup, then set it up as new, and copy the license key file from the backup and keep the rest of the files from the fresh install. All the customization of Unraid is in the config folder, so just keep that securely backed up so you can recreate your config if you want later.

If you duplicate an existing container, they share the data layers in the docker image. There is practically no redundancy and waste when doing this, the only "extra" would be the repeated stuff in the appdata folders.

No, I'd replace it with a stock file extracted from the download I listed above. You can edit it and change the server name to what you had before instead of "Tower" if you want.

ident.cfg is just a text file, like most of the config files. You can extract just that file from the latest download from https://docs.unraid.net/unraid-os/download_list/ and edit it, if you don't remember customizing the entry in the file just leave it as default, you can change things after you boot. Did you look through the other files in your config folder to see if any others were messed up? I think only the super.dat and the key file aren't plain text.

Split level overrides high water, so if the copying method creates empty folders and then fills them, the allocation method won't be applied.

Maybe browser autocomplete "helping" you by populating fields with previous content?

Maybe this from the first page of this thread? https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1131485

The wireguard VPN server built into Unraid would allow that.

I guess I'll try again, but it wouldn't start my world with the 1.20.6 jar and profile. It acted the same before and after I updated the Java version. Got it working, the issue was permissions on the world files I copied from my deprecated binhex mineos container. Now, I just have to figure out how to allow my unMined mapping container to access the world files, it doesn't like the new permissions.

Have you looked at Spaceinvader One's youtube channel? He has a comprensive list of Unraid videos.

The syslog will show the sector number, but there is no way to know which disk is wrong. It's also a very difficult problem to determine which file (or free space) on each disk is being used by that sector.

Can you please explain what you mean? The only way to use wifi with Unraid's base OS is to attach a wifi to ethernet bridge and utilize the ethernet port on the Unraid pc.

or

The correct support thread is If nobody can help there, try https://www.linuxserver.io/support

That was the first thing I noticed, it wouldn't toggle to the light side. Working now, but it got me thinking. Do you have statistics on dark vs. light usage? They would be skewed to the dark side, since that's the default, but I'd be curious what the statistics say.

Have you discovered Spaceinvader One on youtube yet?