sonofdbn

I'm on 6.11.5. Over the last week I've twice had a problem with the web UI becoming unresponsive in parts - some tabs won't open, the main tab shows the unRAID wave in the Unassigned Devices section and after a while the main tab also fails to open. Although the unRAID GUI is unresponsive, other things are running: I can access files and open them. I think the first time the Win10 VM was still running, although this time I can't RDP into it. Both times I've tried "powerdown" via SSH but the server doesn't seem to shut down. The first time I couldn't get into the GUI to get diagnostics (and didn't know that this could have be done via the command line). Unfortunately I can't recall exactly how I shut down the server the first time. Might have been via IPMI. This time (today) I grabbed diagnostics and then tried to shut down via the GUI. Heard the beeps (as before) but after about 45 minutes the server was still on (as before). In the end I shutdown via IPMI. When I rebooted after the first incident, one of my disks was marked as missing. Seemed to be a loose SATA connector; after some replugging I started the server and everything seemed OK. But today I got the unresponsive GUI again. tower-diagnostics-20230714-2143.zip

OK, my (big) mistake. I had set the version to 4.3.9-2-01; I think this was a while back as a workaround for some problem I had. Switched to latest version, and all OK now.

I should add that I'm using PIA and I think my qbittorrentvpn setup is very straightforward. So far still unable to get it going properly. (It's been working fine for ages.)

I recently noticed that no torrents were appearing at all in the Web UI (all categories had a count of 0) and the bottom bar that normally shows upload and download speeds etc. was blank other than a few icons like up and down arrows. I'm on unRAID 6.11.5. Recently I ran "Docker Safe New Perms" to fix some issue in another docker, if that's relevant. supervisord.log

Data rebuild did complete. But there surely shouldn't be random(?) interruptions.

Always seems to happen: I open up the server to do something with the hardware and end up with more problems. This time unRAID (6.11.5) told me there was a disk that had failed, so I replaced it with a pre-cleared standby disk. I took the opportunity to do some general cleaning and change a drive cage and fan position. Then I rebooted and started the data-rebuild on the new disk. After a few hours of rebuilding, one fan got a bit noisy, but looking through the window it seemed to be spinning fine. But when I tried to connect to the server I couldn't reach it over the network. In the end I had no choice but to reboot. So the data-rebuild started again from the beginning (groan). I had lost network connection a few weeks ago, so I'm wondering if there's some underlying problem. (I think the fan and physical changes are just a coincidence.) I'm also hoping there's no problem with the data rebuild. Does unRAID consider a disk pre-cleared (and therefore effectively blank) until the rebuild is complete? (Hence the restart from scratch.) abridged_syslog.log tower-diagnostics-20230625-2228.zip

Thankfully, yes, restarting the server got all the shares back. One thing I noticed after rebooting was that although I had shut down the VMs before running Mover, I hadn't stopped the VM service. Could this have caused the shfs crash? I'm a little concerned that something is causing a problem with Mover if I'm going to incorporate it into regular use.

I'm setting up my second server (6.11.5), and haven't used Mover before. I had set up the share "domains" to "Prefer: vm_nvme" and has set up two VMs. But although there's a ton of spare space on the Nvme SSD, I found the two VM "vdisk1.img" files under "domains" on Disk1 instead of on the SSD. I thought that somehow Mover had run and moved "domains", perhaps before I set up "Prefer: vm_nvme", but it's unlikely because I set up the second VM very recently and way before the scheduled Mover default time of 3:40. Anyway, whatever the cause, I wanted to move the VMs back to the SSD. Doing some reading, I got the impression that Mover would "honour" the Prefer setting and actually move files back from the array to the SSD. (This is contrary to what I had previously thought, which was that Mover only ever moved files in one direction: off the cache pool to the array.) Anyway, I thought no harm in trying - worst that could happen was that Mover did nothing..... So I manually invoked Mover from Settings/Scheduler and nothing seemed to happen. I checked the Main page on the GUI and there wasn't much disk activity (the VMs in total are over 300GB, so any moving wasn't going to be instantaneous). But when I looked at Shares they had all disappeared! I should have had at least appdata, domains and isos. Fortunately it looks like the files are where they were previously. Unfortunately I didn't set up the Mover log. What happened and did I do something wrong? t2-diagnostics-20230617-2223.zip

I must have added at least seven 8TB drives in unRAID and never noticed this really quite large overheard before. My surprise was more that the message says "unmountable", but the disk must have been mounted for parity to be running.

I'm setting up a new server and precleared both the 16TB parity drive (as a stress test, I believe preclearing isn't necessary for a drive that's going to be added as parity) and an 8TB data drive, which I think had data on it before. So I thought both disks should essentially just be blank. After adding them to the array (they're the only two drives), a parity sync started, but at the same time a message popped up for the 8TB data drive: "Unmountable: Unsupported partition layout". So I cancelled the parity check and formatted the data disk. Now it's online but it says that 55.8GB is being used. This seems weird - seems odd that a parity check would start when the disk is purportedly unmountable, and how did I end up with 56GB of data being used? For now I've stopped the array. t2-diagnostics-20230613-1546.zip

I'm trying out HQPlayer Embedded, where you download an .img file and flash it to a USB drive. Then you boot a PC from the USB drive and the software runs in RAM and on the USB drive, without (it seems) writing or installing anything to the hard disk. It works fine this way, but I would like to try to install/emulate this in a VM. I'm trying to avoid having yet another flash drive hanging off my PC. Given that I have the .img file, how would I set up a VM using that file?

I found that I could ping the remote server via its IP address, but not by its name. After some digging around I found that the unRAID system was using my router and Pi-hole container for DNS services. So I manually added the remote server name and IP address (it's static) to my Pi-hole DNS list and now everything seems fine. I don't know if this is the optimal solution, but at least it's working.

Sorry, should have uploaded Diagnostics automatically. A quick look shows that UD found that the remote server was offline, but that server is definitely running. tower2-diagnostics-20230602-0002.zip

I'm trying to add an SMB remote share; the source is on another unRAID server. Adding the share was very straightforward: the UD GUI found the server and after entering credentials it listed the various available shares, and I selected Movies. After mounting this share, my Plex container can access it. But although I set the share to auto-mount, after restarting the server the share doesn't get mounted and in fact the Mount button is greyed out. (The source server is on the whole time.) I've set network delay to 20 seconds, if that's an issue. What should I be doing to get the share to auto-mount? If I remove the share and add it back as a new share, it works fine. (I'm on 6.11.5.)

It's been a long time since I last looked for a PSU. Having looked around, I now realise it's actually a little difficult to get the lower wattage PSUs, at least where I am.

A little further digging around - the manufacturer seems to be Changwang and their website has BIOS downloads here and other things. I had to use Google translate a bit.

That's a very interesting build - maybe I should try something like this rather than trying to add some horrible homemade DAS to my current server. So tidy as well, compared to my cable mess! Do you need a 750W PSU? I'm running 10 hard disks off a 650W Corsair PSU. Not criticising - just budgeting 🙂

I found a relatively simple way of finding the GUID of a flash drive in Windows: 1. Get USBDeview (free) from NirSoft here. 2. Run USBDeview and find the flash drive. 3. Double-click on the flash drive and a Properties window will pop up with lots of fields. 4. My GUID comes as 4 digits - 4 digits - 4 digits - 12 characters - first 4 digits are VendorID - next 4 digits are ProductID - next 4 digits and the 12 characters come from the last 16 characters of Serial Number (which is ridiculously long) (This information can also be extracted from just the Instance ID field.) This is basically from looking at just one flash drive, so it's certainly not extensively tested, but this might be one way of checking for useable GUIDs before trying to flash unRAID onto the drive.

I appreciate the suggestions, some of which I was aware of, but it comes down to cost. While maybe not technically server level, these are expensive solutions, including the (very interesting) AMD iGPU transcoding thread you linked to, which requires DD5 RAM. I do admit I didn't know that Ryzen 7000 series CPUs included iGPUs. While I know that ECC RAM is not an unRAID requirement, I do prefer it, if only to give me a little peace of mind. But it does seem to complicate and severely limit the range of options. I did look at older used Xeons, but then (of course) they generally don't support transcoding. The tech gods truly don't like ECC and transcoding being done on one CPU. I would prefer to keep everything in one box, but one alternative suggested elsewhere is to offload Plex onto a used small desktop PC with at least an 8th gen Intel CPU to do the transcoding (while keeping the media files on unRAID).

I'm planning a second unRAID server, and ideally I'd like to have ECC and be able to handle some Plex transcoding from 4K. But it seems incredibly difficult to find a straightforward solution that doesn't involve server level hardware and expense. If I want ECC, seems like an AMD CPU is the way to go, otherwise I have to go with Xeon CPUs. But Plex hardware transcoding doesn't support AMD CPUs, and Quick Sync on Intel seems to be the optimal transcoding solution. (Partly for noise and power reasons, I'd prefer to avoid getting a separate GPU just for transcoding.) Are there some good solutions to this? I rather hope I've missed something obvious. (I do have some other things I might want to do with the server, but I'm trying to tackle things one at a time.)

My 2 cents as a non-expert: If you want to reduce the risk of data loss as much as possible, then ECC RAM will help. How much it will help is the big question. I haven't seen any empirical evidence of the benefit of ECC RAM. I believe it's entirely possible that you could run your server for years with non-ECC RAM and never have an issue that ECC RAM could have avoided. It's a bit like travel insurance - you could fly many times and never have a problem. But if disaster strikes, you (or at least your beneficiaries) will be very glad you had travel insurance. If you have the budget and if you can get the components, then I would say go with ECC RAM. Personally I do have ECC RAM, but am not sure I would get it for a new server. But that's because where I am it's difficult and/or expensive to get motherboards that support it. And honestly I got tired of trying to work out which AMD CPU/motherboard combinations actually officially support ECC RAM. OTOH, Intel solutions seem to be very expensive.

Unfortunately I lost the network connection again. Running my untrained eye over the syslog, It looks like the same problem. I've attached a truncated syslog. Both VMs, Win 10 and Win 11 were running at the time. I'm going to try running just the Win 10 VM, which I've been running for a few years (without this problem). If the cause of the disconnect is indeed the Win 11 VM, the next question is how do I fix it? syslog-192.168.1.14.log

I think I was running two VMs at the time, one Win 10, the other new one, Win 11. Do you mean try with no VMs at all, or just one of the VMs? And if so, which one was the cause? (I should be able to identify by CPU number?) In any case, touch wood, hasn't happened again since rebooting.

Tonight I suddenly lost my network connection to my unRAID server. First time it's happened, and I haven't touched the hardware for at least a week or more. Only significant change over the last week was adding a Windows 11 VM and isolating some CPUs. I had to reboot to get the server back online. I've attached syslog and diagnostics. Would appreciate any suggestions about what went wrong and how to fix it. syslog-192.168.1.14.log tower-diagnostics-20230506-2305.zip

In the GUI only a few torrents were listed, but I have many more that should have been seeding, and on the docker page the container was showing some percentage of CPU activity (2%-3%), not consistent with no/minimal activity. Anyway, getting a bit desperate, I tried installing the libtorrentv1 version as a new container. I started the new container but although I had changed the GUI port I didn't get any login screen. Then I realised that the original container (4.3.9-2-01) was still running, and perhaps illogically thought that might be the problem. So I stopped it and went looking for differences in the appdata folders. There I found that I had messed up because although I changed the container name for the new version, I had forgotten to change the appdata folder; so it used the same appdata folder as my current problematic container. So I stopped the new container, gave it a new appdata folder and restarted. Same problem, couldn't get to the GUI. So stopped it, and started the old container to see what had been damaged by installing into the same folder. But miraculously the old container was now working! So problem solved, but no idea what fixed it. I realise there's zero interest in this from anyone else, but I leave this here in case it helps @binhex in some way.