JonathanM

Please read the very first post in this thread.

Google search this string and tell me what you think. unraid safari site:forums.unraid.net

This situation has brought to light something that I think needs to be fixed. @bonienl, can you please take a look at the last several posts? Something needs to be changed to clarify the situation, but I'm not sure how to best approach it.

That's strange. Can you click the EDIT button on that path and screenshot what shows up?

screenshot?

The docker config page. You told it to map /mnt/user/Downloads on the host to /downloads on the container.

True. What I posted would work, but it's not what he intended to do. @BennyD, what strike posted goes in the first and second blank.

Where it says "Download to:" needs to be set to /downloads if you docker run command is current.

Yes, VM's especially should not be set to auto start. Any VM hardware passthrough will have to be redone.

The only thing I can think of is to set the array NOT to auto start. That way if something is hinky you can investigate and fix before the array takes off on you.

Unraid would see that all of your drives were different, and would refuse to start. It uses the serial numbers to keep track of drive assignments, so the ID string that the original H700 assigned would no longer be valid. Same thing would happen if you put in a new H700, all the disk ID's would be different. You should manually keep track of which serial number drive is assigned to which logical slot in the unraid array so you can reconstruct the array if something breaks or changes. As far as re-formatting, that depends on how the H700 passes the drives on to unraid. If the drive content is presented identically, then no change is needed after you tell unraid which drive belongs in which logical slot. If, however, the RAID controller does something cute like truncate all the drives by a small amount to ensure identical sizing or keeps RAID bookkeeping info on the drive, then it's possible they would no longer be recognized as having valid partitions.

Or, since the USB doesn't get written to very often, that change you made was the first attempted write to the USB. Disks aren't marked bad until an operation errors out. Doesn't mean there wasn't a problem before, just that there was no reason to notice until the activity.

I hope you have good backups elsewhere of data that you keep on your server. Overclocking is risky, as you've found. What seems stable because the server doesn't outright crash doesn't mean everything is working accurately. Overclocked server is a combination asking for trouble.

Be aware that using a RAID controller for unraid is a bad idea. Please read this entire thread.

Yes, as long as disk4 is not excluded in the global share settings. All root folders on any disk are automatically included in user shares. If you want to, you could globally exclude all your currently formatted ReiserFS disks in global share settings, then as you finish verifying the copy and format them XFS, remove them from the global exclude. Then your user shares will only show the items on the XFS disks. BTW, while this is going on, don't write any new content to the user shares on the server if you can help it. If you must add new content, make sure you confirm exactly which disk it goes to. Reading existing content is fine, just no additions or especially no edits or modifications to existing files, unless you do the global exclude trick I was talking about.

Remove / reattach CPU heatsink to verify square solid attachment with good contact.

Are you POSITIVE the server is plugged in to the correct outlet? Some UPS's have both battery protected and surge only outlets in the same area, distinguished only by some vague labels.

Depends on the penmanship.

The docker engine is part of unraid, but your choice to install and run a specific docker, like krusader or dolphin, is purely your choice and your responsibility to secure. If you secure the main GUI with a password, nobody can log in and start or install any dockers. If you leave krusader running, that's on you. In general, assume unraid is insecure and needs external protection, in the form of firewalls and physical security. It has no place being deployed directly in a public place, either physically or a public network.

Definitely. If you can document the process needed to get the database manager usable in a docker image that runs on any linux, but unraid specifically, that would be great.

Yes. When the monitoring agency sweeps the IP's of a torrent swarm for a targeted download, they will get the VPS IP address. This tracks back to your server account at the VPS company, NOT your home ISP. If they actually care about it, they could easily track you down. Thing is, the enforcement companies are lazy, they typically don't bother doing any actual work, they just send bulk demand letters listing offending IP's to spectrum, att, comcast, verizon, etc. If the VPS company actually receives an extortion letter, they might forward it to you like the ISP does, but I doubt the enforcement firms even send letters to them. BTW, if a law enforcement agency (not civil litigator firms) actually want to find you and are willing to dedicate the resources, a VPN service is NOT going to help.

If the ATT modem is forwarding WAN port 80 to LAN 180, and the google wifi is connected to the ATT LAN, then you need to tell the google wifi to forward port 180 to your unraid docker IP, not 80. The info has to make it all the way through and back. Internet port 80 <-> 80WAN ATT moves it to 180LAN <-> 180WAN Google Wifi 180LAN <-> 180 Docker LE 80 to application. Same thing with 443. The next device in the chain has to be listening to the correct port, you told google wifi to listen to 80, and the ATT to talk to 180.

Depends on your skill level. "Best" is not helpful if you can't accomplish it. 1. You don't want to move the files, you want to copy them. This accomplishes 2 things. It keeps the original available as a backup and compare to check the copy was successful, and it is much faster than moving because a move deletes the source files, which is EXTREMELY slow on a full ReiserFS disk. 2. There are MANY methods available to copy data from one disk to another in unraid. Be sure that for this specific purpose you NEVER work with /mnt/user paths, always /mnt/diskX when using console or docker. If you do it over the network, only work with the disk shares, never user shares. Then when you are totally done with the migration, I recommend turning disk shares back off. a. console command line rsync b. console command line cp c. console text GUI midnight commander d. docker GUI Krusader e. docker GUI Dolphin f. network client copy with disk shares enabled Pick a method that you feel comfortable with, and ask for details accomplishing the copy if you need them. BTW, if you add your old parity drive as a data drive as well as the 10TB, you should have enough free space on the array to copy all your data to the newly formatted XFS drives. Then after you are satisfied that all data has been copied, you can either remove all the old drives and keep them as backup, or leave them in the array and format them as XFS for additional space. If you choose to remove drives from the array you must rebuild parity after the drive(s) is/are gone.

If that UPS is using SLA batteries, you are seriously killing the available life of the batteries by waiting that long. Ideally the server should be shut down completely before you get to 50% capacity. The purpose of a consumer type UPS is to allow for a clean shutdown with enough time to finish critical tasks. If you need extended runtime, you need a different solution.

First, which version of unraid are you running? You posted in an area for a VERY old version.