itimpi

If anything it is the opposite to deprecated. Since it understands Unraid User Shares it stops you making certain types of errors that can lead to data loss if doing certain operations with other file managers. Since this plugin now appears to be stable I could see it becoming baked in functionality.

It is not in the 6.12 release so I would think late 2023 or 2024 is a likely timescale if it is treated as the next major feature to add. Could be later if something else is deemed more important.

The big problem with making something like this baked in is that it would mean long delays between updates. It only makes sense to bake it in when updates become infrequent. This is one I agree with. The issue of reiserfs and disks larger than 16TB has been known for some time and there should be a baked in check for this to stop you setting reiserfs up in such a scenario. Simply mentioning the issue in release notes is not sufficient. I also think that with the advent of reiserfs support being removed from the Linux kernel any users still using it should be forced to acknowledge that they know about the issue so that they get on with converting any existing reiserfs drives off that file system before support gets removed from Unraid. Having said that I admit I have not checked to see what happens on the 6.12 release if you try to set up a new disk with reiserfs.

The New Config tool is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Perhaps it is worth posting your system's diagnostics zip file so we can see more about how you have things set up at the moment.

It looks like that is a 18TB drive ST18000NM000J-2TV103_ZR5CLZVV. You should carefully check SATA and power cabling to this drive. You want to avoid too many drives hanging off a single power cable.

You only tend to get rapid updates during a rc phase or just after a new stable release when bugs are found with the wider audience using it that were missed during the rc phase.

Not looked at the diagnostics yet, but you should enable the syslog server (probably using the option to mirror to flash as easiest to set up) so you can get a log that survives a reboot.

You should at least try enabling the syslog server (probably using the option to mirror to flash as being easiest to set up) so that you can get a log that survives a reboot.

This normally means that there is a bad connection to the drive (either SATA or power). You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Not necessarily. I thought you found you had a bash shell running with the current directory being on the array. That WOULD stop the array from shutting down correctly.

That is the part of Unraid that supports the User Share capability.

Have you read all the online documentation? Not sure what you think is lacking so mentioning where you see the omissions might lead to those parts being improved.

That was the first post in this thread! I did not realise you cross-linked to another thread

That is a problem reading the flash drive Quite often you can fix this by downloading the zip version of the release from the Unraid site and extracting all the bz* type files overwriting the copies on the flash drive. If that does not work then it is possible the flash drive is starting to fail. Make sure you have a backup of the ‘config’ folder off the flash dtive as that contains all your setting.

Have you tried swapping the power and SATA cables with another drive to see if the problem follows the drive? The extended SMART test is completely internal to the drive so would not show up any potential cabling issues. If the problem follows the drive then that suggests the problem really is the drive.

My upstairs neighbour had exactly this problem and it turned our to be his Fritz box (he is not an Unraid user)!

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

No, that would not survive a reboot ad that location is in RAM. you need to do this either with entries in the config/go folder on the flash drive, or by using the User Scripts plugin and set an appropriate script to run on first array start.

Something that occurs to me is are you sure you have the right cables? The forward and reverse breakout cables look identical but are wired differently.

reallocated sectors could only be considered minor if the number is relatively low and is also STABLE. This last criteria appears to not be met.

If that has more than one drive in it then it must be using a port multiplier internally to get them to run over a single eSata cable connection.

Since you are running Unraid 6.11.5 you can install the Docker Patch Update plugin to fix this.

In theory they should only be a performance issue, but experience has shown they can also sometimes cause other issues such as spurious drive failures.

Just realized that the syslog file you provided is from the syslog server and the log entry referencing NerdPack is an old one - sorry about that. If the server is stable when booted in Safe Mode it is going to be one of your plugins - but not sure which one it would be so it may be a case of eliminating them one at a time. You can disable any plugin by renaming its .plg file to have a different extension and rebooting. I would probably suggest starting with the gpustat one simply because it appears to be some time since it was last updated with the next most likely one being the NVida driver one as being the most instrusive. However those are just guesses as I have no specific reason to assume which would be the guilty suspect.