apandey

You didn't have to do that, non default share names are confiscated in diagnostics. All I see is S--a I don't see anything special in diagnostics, except for a warning about usb boot drive filesystem. But that should not cause issues during file copy after system is already booted Was the diagnostics during a file transfer? If not, do it when transfer is running. If yes, or if nothing else comes in diagnostics, wait for reboot and then let's look at syslog saved to usb drive

Post diagnostics so we know a bit more than the symptoms Also, enable syslog mirroring to flash drive and see what ends up there leading to the reboot

We would be guessing unless we know more. Please post diagnostics if that happens again

It is not always just about ads, I find pi-hole or similar (I personally use pfblockerng) also useful to protect against malware etc. Ideally a server "shouldn't" have anything nefarious, but all security related attacks succeed because something unknown that shouldn't happen actually happened. Unraid itself isn't focused on security, so it's prudent that it comes from outside it and the network / firewall infrastructure around it is a decent way to get there Besides, if one is protecting their home network, it better be through a single pane of control than to worry about different devices having their own gateway to the big bad internet. For that reason alone, it's a bad practice to whitelist unraid from the rest specially if one is running a lot of stuff on it. At the very least, it gives one a good place to monitor and audit what is being connected to, you may be surprised

I would say check connections in USB enclosure, but then you probably cannot do that remotely. One of the issues with USB enclosures is that they are not passthrough and fiddle with disk names (and possibly more). It can be something as simple as a bad connection to something more severe like a failing USB controller. If you have to replace the enclosure, the names will change and you may be forced to do a new config

how is your cache set up w.r.t. the shares? simplest would be to: 1. stop docker / VM services (not just VMs and containers, but services themselves) 2. set all shares that use cache to cache=“yes” (make note of what they are set as so you can go back to that) 3. run the mover, make sure nothing remains on cache 4. set all shares to cache=“no” 5. again make sure nothing remains on cache, else go back to 3 🙂 6. rebuild cache as btrfs mirror 7. set all shares to original cache preference. If there were any cache=“only”, first set cache=“prefer”, then run mover and finally switch to “only”

is your array healthy? I see couple of issues from your diagnostics disk16 seems to have a corrupted filesystem. Do you see all your array disks mounted? Not directly related to disk14, but I do see it discovered as a new drive and mounted into unassigned devices. Can you post a screenshot of your UI Main tab? you also seem to be getting PCIe BadTLP errors. perhaps you should add pci=nommconf boot parameter

Post diagnostics to start with

Not possible without setting uo some sort of indexer that can interop with macOS spotlight See this (specifically last paragraph of first post) And this

Point it there and see if pi-hole is blocking anything that it should not. Any dns is fine, as long as it answers correctly

Adding a reasonably sized cache drive (preferably ssd) might help. New file writes will go to cache and move to array at scheduled time without interrupting reads from array The drive head has to continuously move around increasing seek time and slowing down read bandwidth

I would be surprised if unraid had drivers for your tape drive. In case it doesn't, your best bet might be to backup from a VM where you have the drivers and the tape drive is passed through to the VM. You will also need to mount your unraid shares inside the VM As for how to backup, you usually use drive manufacturers software where available. If not, tar was specifically built to archive to tape I have to wonder about your data size and use case though. Do you have long term snapshot archival requirements? Whenever i think about tape, creating a backup NAS always turns out to be cheaper and simpler option in my mind - but my use case is all about redundency and backups, so a zfs backup with 30 day snapshots is enough for me

If it was an array with parity protection, you can simply replace disks one by one and let unraid rebuild the data onto new ones using parity (needs biggest disk in array to be parity). But since it's a single disk, best bet is to mount old disk as unassigned and do new config with new disks, then copy over data Unraid manual linked on top of unraid UI has instructions on all these procedures but feel free to ask here too

Yes. Specially if you don't care about data on the array. Just need to do new config for array with new drives You can also create an array with just a usb drive, which is simplest way without locking up a disk if you don't want to use the array

This is often overlooked / misunderstood. Sequential reads / writes are the simplest operation spinning drives can do, and doing it many times over is something the drive should be able to do easily without any detrimental effect. It's also reassuring that we know the drive can read fully - that's why we actually run routine scrubs and checks. If I suspect a drive will not be able to take a few full read/write cycles, I would be swapping it out

Shares can reside only on pools (cache=only setting), so doesn't have to be array only Also, you can pass through disks by-id to your VMs, so for your use case, you can just pass the disks directly rather than vdisks on shares But unraid needs at least 1 drive in an array, so you have to think about that too.

The ones with M in model name are managed, without are unmanaged. QSW-M1208-8C vs QSW-1208-8C

Good point about that. It has a 40mm fan, so it's not silent. That's tricky for 10gbe switches as many have fans. How loud is relative given the landscape. Some of their unmanaged switches with less number of 10gbe ports are fanless if I remember, but not sure which ones Prices seem to have shot up recently. It used to be around $600 last year. But this is 12 ports. Look at M408-4C if you are ok with 4 10gbe combo ports and 8 1gbe ports. That used to be around $300, but again seems higher now. Check on camelcamelcamel for price trends. There are also 2C versions. It all boils down to how many 10gbe ports you can budget for. Like for like, these are still cheaper than alternatives and the combo ports provide a lot of flexibility if you haven't planned the network from the start

Perhaps post diagnostics so someone can look into details

No Perhaps post diagnostics so someone can see what is going on with your system

Carefully look at your docker containers and see if any of them are continuously crashing (looking at uptime will tell). Find out why, it can be something as simple as a port conflict

This is correct. Raid-Z level reshaping is not possible in zfs. The level needs to be decided at create

To both your questions - each port negotiates link speed independently, so connecting a slower device won't slow down other ports. You can daisy chain switches, but read up a bit on network loops and spanning tree protocol to avoid them. Make sure your switches support STP. I myself has 3 edge switches connected to my main one at home. The qnap I mentioned supports 1G, 2.5G, 5G and 10G links on the RJ45 ports, so maybe you don't need to chain the switches unless you need more ports.

Qnap makes some well priced managed and unmanaged 10g switches with various combo port (sfp/rj45) configurations. I would recommend something like QSW-M1208-8C, but you can get other configurations with 4 and 2 combo ports too. Look at the QSW series. You can also get 4C or 2C models with some 1G ports if you don't plan to expand further. These are very popular in homelab community I would go managed rather than unmanaged if you plan on learning further. No point getting hamstrung down the line Also, be aware that saturating a 10GB link is fairly difficult in a homelab setup unless you eliminate all io and processing overheads. It really only works when you have fast storage, parallel compute and are not dealing with filesystem overheads of small files

I agree with JorgeB. It may not look to be the fastest, but it's the safest way to upsize, while being protected by parity all the way. You should also consider that replacing disks one by one also means you don't have to take extra steps to copy data across and deal with any other additional steps which can cause an error, so some of the time you spend doing it slowly is recovered by you not having to nervously sit while you move data around