GrantE

I have...had...a lovely 80TB unraid server. Then my house flooded and everything is destroyed. I have backups of the config and docker containers. But it will be awhile before I have hardware to restore them to. Things are tough right now and I really want to get plex back up with a bit of content for my kid so they can have a bit of normalcy. What I do have is a hyper-v server at a friend's house I can setup some VMs on with a tiny bit of storage (at least compared to the server that got flooded). Far from ideal, but better than nothing until I can get things sorted out. Can I run unraid in hyperv as a VM without any USB drives, even in trial mode for a couple weeks? That would let me directly restore all the docker configurations instead of having to setup docker manually on a Ubuntu VM or something. I tried the manual install instructions, mounted a VHD file, format FAT32, name it UNRAID and copy the files over etc. When I boot it, it gets to the point of "Waiting 30 seconds for device with label UNRAID to come online", but can't find the disk. I double checked and when mounting the disk it does come up as UNRAID and a FAT32 drive. So I can't get past that. I can probably get them to put in a USB drive if needed for licensing the trial license or even installing to, but not sure if I can boot from that in Hyper-V on server 2019. Any ideas how I can get something running temporarily? I'd be very grateful for any ideas you might have.

I ran into this issue as well, and Geoff Bland's solution worked for me. However, I found a way to make it even better and not have to reset any permissions! I don't know if it will work for everyone, but it worked for me and all my AD users and groups kept the same uids. First you need the uid of any AD user - you can get this with 'wbinfo -i <username>' or by looking at file permissions ('ls -n' will show the numeric user IDs instead of converting them). Then you need the RID of that user. You can get the RID with 'wbinfo -n <username>' or in active directory look at the objectSID property for the user. The RID is the last section of the SID. In my system: UID for my user is 1161823314 SID for my user is S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1106, so my RID is 1106. Subtract the RID from the UID. That gives me 1161822208. I don't know if that number will be different for everyone. I'm guessing it will be. Then set the start of the range for the id mapping to that value. The rid mapper adds your RID to the low end of the range, so all your uids should match what they used to be. Same as in Geoff's solution, edit /boot/config/smb-extra.conf and add this to the [global] section: # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid. idmap config * : backend = tdb idmap config * : range = 1000-7999 idmap config MYDOMAIN : backend = rid idmap config MYDOMAIN : range = 1161822208 - 4000000000 Then reboot the server. Just restarting samba doesn't work, and I didn't fight with it long enough to figure out why. But rebooting does work. Once that's done, you can run 'testparm' to see the final configuration samba is using. It should include your idmap config lines, and should NOT include the default 'idmap config * : backend = hash' anymore. Test your users with 'wbinfo -i username' and make sure their user IDs all match what they were before, and that any broken users work now. No need to reset any file permissions!

I have my unraid server attached to a separate disk shelf for more storage (because they just don't build big cheap cases like they used to). Not a real commercial disk shelf, just an old case with a PSU, SAS expander card and drives in it, connected via external SFF-8088 cables to a HBA in the server. Right now both the server and disk shelf are on the same UPS, so if they lose power and the UPS dies, at least they die at the same time and it's no different than if they were all in the same machine. But I'm thinking I may need to split them up across 2 UPSes. Which means that one UPS might fail before the other. Even if I don't use 2 UPSes, this could come up if the power supply in the disk shelf dies. What is likely to happen if unraid suddenly loses access to half its disks while the array is running?