itimpi

Option to shutdown the server if any array or cache drive reaches the threshold you define has been added. If set this will function independently of any array or cache operation being active. The prime Use Case is seen as protecting your drives if your Unraid server's cooling fails for any reason.

As far as I know most common brands work fine in the 6.8.3 release. 10Gb NICs have been around much longer than 2.5Gb ones.

Are you saying that if you plug the USB drive into another machine you cannot read it’s contents? if you can immediately copy it’s contents as a backup. if you cannot read the USB drive contents but have a backup on an array drive then there are ways to get at that. Examples are to use a ‘trial’ Unraid licence or use a standard Linux ‘live’ build to get at the drive (Unraid uses standard Linux file systems). if none of those options are possible/practical for you then we need to know more before giving advice on the best way to recover.. For example do you run dockers/VMs that also need recovering?

In practise most commodity hardware works fine unless it is niche in some way. The one ‘gotcha’ can be when you have hardware that has only recently been released for which there may not be the relevant Linux drivers already included in Unraid as it is not easy/practical to add them yourself for the average user. Limetech are very good about adding drivers to new releases once the manufacturer releases them for Linux but this takes time. A good example of this is the relatively recent situation of 2.5Gb NICs becoming commonplace on new motherboards. Support for these is not in the current 6.8.3 stable release but has been added to the 6.9.0 release (currently in beta). As was mentioned the best thing to do is post the details of what you are thinking of using as there is an excellent chance an existing Unraid user having experience of the hardware and can give feedback. If not direct experience they may be able to direct you to relevant forum posts.

Tools -> New Config

I would not expect the machine that is behind that router to be able to accept incoming connections (unless that router happens by chance to be setup so that incoming connection can be specified by the server using DNLA).

It would have been unmounting disk drives (not shares) which is a standard step in stopping the array.

I think you are getting confused between the default format for array drives and that for cache drives/pools. For cache it always defaults to btrfs (and this is the only option if there is more one drive in a pool) and you have to manually change it to get something else.

2) With the rate at which hardware changes it would be impossible to keep such a list up-to-date. This is one of the main reasons why Unraid has a trial license (valid for 30 days and extendible for an additional 30 days) so that you can check it runs on the hardware you want to use. Note that if you have very new hardware then you probably need to use the 6.9.0 beta release as it has a much newer Linux kernel and newer drivers than the current stable 6.8.3 release.

It works fine on my VMs - not sure why you are having a problem.

yes - as long as that is the correct serial number for the disk you want to pass through. FYI: the /dev/sdX number do not change often as normally they are allocated in the order Linux sees them (which is timing dependent so normally consistent (but not guaranteed). However if you accidentally pass through the wrong disk because the sdX value changed it can be catastrophic making the contents of that disk corrupt - not something one wants to take even a small chance of happening.

This entry will typically be of the form source dev=/dev/disk/by-id/xxxxx where 'xxxxx' is correct for the disk in question.

If you look under /dev/disk at the Linux level you will see several folders giving ways that drives are identified in an invariant manner.

Not quite true - this user DOES exist at the Linux level (look in /etc/passwd to see users at the Linux level) - but not with the ability to login to the system.

You will not be able to add the 8TB drive as a parity drive. It is always possible that the disk in question has not really failed - I would wait for feedback on that as that would simplify things. If the drive really has failed then in such a scenario one should use the Parity Swap procedure which is covered here in the online documentation.

The sdX designations are always subject to change as they are assigned dynamically by Linux. Unraid does not rely on the device name to identify drives, but instead the disk serial number.

It is really up to you as to which you will find most convenient. I normally use the option to retain all settings and then when I return to the Main tab make any appropriate adjustments before starting the array (as that typically involves the minimum amount of effort for the sort of change I am considering). The end result should be the same.

Why do you even want to use the sdX type name as that is subject to change at any time if you reboot (as the sdX names are assigned dynamically by Linux during the boot process). Is it possible for your use case to use one of the names that show up under the /dev/disk hierarchy as these should be invariant.

It looks like you currently seem to have 8 drives set up in the array but only 6 physical drives + 2 parity drives. The missing array drives are being emulated using the combination of the other data drives plus the 2 parity drives. A screen shot of the Main tab would confirm this.

I think that Apple mandates that all browsers on iOS use their rendering engine, so this is probably an issue (bug?) at that level.

Not sure I agree here. Changing slots still does not necessarily mean you want the shares to be set up any differently. Perhaps the best way forward would be to add a new check box to the New Config dialog as to whether shares settings should be left unchanged or reset to defaults? At least that would give visibility to the effect that share settings might be affected. Making the default the current behaviour would mean users only get the share settings retained if they explicitly ask for them. do you think this should explicitly be raised as a feature request?

A reboot will fix that as Unraid unpacks itself into RAM from the archives on the flash every time it boots.

I suspect that technically this is not a bug in that the New Config is working as designed. Having said that I agree it might make a lot of sense to leave all share settings unchanged when usin New Config - especially if using the option to retain current disk assignments. I personally would find that more convenient than current behaviour. I do not like your second option as that would cause problems for users who have their shares exported and set to Public.

I think he showed it starting up under a DOS emulator. It may well have been Unraid v5 if the emulator was only 32 bit. Seem to remember though that although technically it was running it took an inordinately long time to boot (several hours?) so was not viable except as a thought experiment

You don’t think the fact this is a show-stopper is not relevant