itimpi

I assume you mean the "Run Script" option to run it in the foreground? If so the log is the contents (if any) of the window that then opens. If nothing appears there you should not expect anything to appear in the log.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

Any method you like. If doing it via Windows you might first need to run Tools->New Permissions on the Lost+Found share to ensure the permissions are correct for doing this over the network. If you want to do it locally on the Unraid server then the Dynamix File Manager can be used.

If its only going to be for a short period I would say mirror to flash as easiest and catches the most information.. If it will be for any significant length of time then use the remote syslog server field to log to the location you specify to avoid wear on the flash drive.

Restart you array in normal mode

Note that the red 'x' against a drive does not necessarily mean it has failed - just that a write to it failed so it is no longer in step with parity. Far more often than not the drive is fine and the write failure was caused by an external factor (e.g. stat or power cabling). The best way to check out the drive is to run an Extended SMART test on it. You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs. Was there any data on disk3 that you want to try and recover? Do you still have the drive that was in that position? What is the state of you backups (if any). Good chance that most of the data can be recovered if you still have the disks that were disabled intact.

Plugins can already add tiles, so I see no reason you should not be able to do this by using the same technique that they use.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. it is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

I ‘think’ that should work. As far as I know the order of the options is not relevant, just that they are correctly entered. Guess it is a case of try it and see.

This is bypassing SMB and going in directly at the Linux level. It has to be via a network share for it to work.

The entry for the GUI mode has a comma rather then a space before the /bzroot-gui option. The options are meant to be space separated, so having a comma instead will stop the /boot-gui being recognised as an option.

It is due to the fact that you had an unclean shutdown while a manual check was running and the plugin does not clear the state information for the manual check after the reboot when an automatic check starts so it is triggering an internal check on state for a scenario that is not meant to happen.. This should auto-fix itself when the automatic check finishes, but if you want to stop it immediately you can delete the party.check.tuning.manual file in the plugins folder on the flash drive. The next release of the plugin will handle this scenario more tidily.

The resume should be automatic if you give it a few minutes with no user action required. If it is not then please enable the Testing mode logging in the plugin and then after recreating the error post your system's diagnostics. That should give enough information for me to work out why you are not getting the check automatically restarting..

You have the Docker Folder plugin installed that is incompatible with your Unraid release and can produce the symptoms you describe. Its functionality is instead available via the Folder View plugin on the latest Unraid releases.

It seems much more likely that the server has "forgotten" which drive should be the bootable drive. You might want to check that the BIOS battery does not need replacing. In terms of 'fixing' the original drive if the problem is that level I would suggest following the steps outlined here in the online documentation to replace all the bz* type files to see if that helps. You can do this with the latest Unraid release so it should not matter what release you were previously running. You can do this, but then you will have to go through the automated licence transfer process to get an updated licence file for the new flash drive. This process blacklists the old one so you might want to first try the suggestion of replacing the bz* type files on the old drive.

It works perfectly well for me and as far as I know others who use it. That was why we were looking to see if there was something we could spot in your setup that would stop it working for you. Still puzzled as to why it is not working for you.

This is not an Unraid issue as Unraid does not support WiFi so the Mac must be connecting to your router via WiFi and that is what you need to look into.

It might be worth seeing if @JorgeB has an idea? I seem to remember that there is an ‘included disks’ bug that can perhaps be relevant, but I am not sure of the details.

Yes. disk to disk moves will work as that explicitly places files but not sure why your user share to different user share is not working as expected.

Do not know why you are not getting expected results then. Reason for asking for what you were using is that if you use Move from something like Krusader or 'mv' at the command line you can get files unexpectedly staying on the same disk because of the behaviour described in the Caution in this section of the online documentation. Dynamix File Manager implements move using a copy/delete strategy so should not suffer from this issue.

What are you using to try and move the files?

Those two settings are not really related to each other. one controls grouping of items while the other controls overflow to another dtive. I do not see why a Split Level of 1 is not working for all new files if you are using High Water Allocation method. Unraid will not move files between drives, so if your previous settings scattered files then it is a manual clean up activity.

Not sure I understand you. That allows you to control exactly which disk any file ends up on so you are manually making sure files are not split when not wanted.

No - select from /mnt/disk1/media_Movies and move it to /mnt/disk2/media_Movies, etc. do not try to mix User Shares And Disk Shares in the same operation. Dynamix File Manager will not let you transfer between User Shares and Disk shares (or vice Vera) as this can lead to data loss if you are not careful.

Maybe you are misunderstanding Split Level? What is the path for the files for a given movie? If they are all in a folder named after the movie then you might need a split level of 2 to keep them all together. If you do have everything at the top level, then you want to be using the Highwater allocation method as that would keep files together except in the rare cases where a particular file reaches a trigger point so Unraid switches to the next disk for the next file. The Most Free allocation method would almost certainly put related files on different drives a lot of the time.