itimpi

Just posted the update. If it still goes wrong then try and get me diagnostics with the Testing mode logging active in the plugin.

You should post this in the Unassigned Devices support thread as it that plugin that handles remote mounts, not the core Unraid system.

Unraid recognises disks by their serial numbers - not by where they are connected so physical connection order does not matter. If you have any hardware passed through to VMs then it is highly likely that the hardware IDs will be different on the new system so you should make sure no VMs are set to autostart, and remove any passed through hardware settings. You can reset these as required once the system is up and running on the ne hardware.

Do you have a monitor directly attached so that you can see what is happening during the boot process? Sounds as if it may not be completing.

You could also try enabling 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 restart. If using the mirror option the syslog file is stored in the 'logs' folder on the flash drive.

This is meant to be part of the 6.13 release, although what restrictions around VMs starting might still apply I have no idea.

It might be worth providing a screenshot of the settings for a share you are trying to access. Make sure its Export option is not set to 'No' as this would mean it will not be visible on the network.

Have you rebooted? That might be enough to reset everything as changes made to RAM files are not persistent. If not then this section of 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 shows how to reset the root password.

You need to be very careful when using Krusader that you do not try to copy or move files between a User Share and an array drive or pool as that can lead to loss of the data involved. The Dynamix File Manager will protect you against this.

How did you change the username? I did not think it was possible to use anything other than root as that is baked into Unraid.

Going through a reboot sequence should not generate the notification spuriously so it is possible in your case the notification was genuine. The issue I have found relates to stopping and then restarting the array without going through a shutdown or reboot sequence.

Thanks - I see what is the issue now and have reproduced it? That notification is erroneously being generated as you are stopping the array without doing a full shutdown or reboot as I am getting an event from Unraid I did not expect during the stopping sequence. All my recent testing concentrated on using the Stop or Reboot buttons to get a tidy shutdown or deliberately forcing an unclean shutdown. I had been a bit lazy and skipped doing the simple array stop/start thinking it was not relevant to unclean shutdowns . Can you confirm that you are getting the notifications while stopping the array? I will work on an update that will fix this issue.

The script you have posted looks like a version used by the Mover Tuning plugin. My guess is that the error message is something to do with the way that plugin is installing itself during the boot sequence, so you could ask/report this in the support thread for the plugin.

Do you have the file 'config/vfio.cfg' on your flash drive. If so then try deleting that to see if the system then boots as that file is used to specify hardware that is passed through to a VM and is therefore unavailable for Unraid to use. BTW: When first trying with the VM start by NOT assigning any graphics card to the VM and let Unraid emulate one that you can access via VNC. You only need to pass through a GPU if you need to maximise performance of the GPU.

At the moment I am very confused. According to the syslog in the diagnostics the plugin has never written a notification (it writes a syslog entry every time before trying to generate a notification). It is almost as if there is something stuck at the Unraid level that is causing this repeated notification but I cannot think what that might be. BTW: You had the 'Debug' level of logging enabled - to do a more thorough analysis I would need the 'Testing' level of logging enabled.

It is frequently reasonably correct. Your can probably gauge how much space is showing as used compared to what it was before. The linux 'file' command can help you determine the exact media type, but it is a lot of work to recover from the lost+found folder so if you have backups this is normally easier. If you still have the 'failed' drive intact then there is a chance that running an xfs_repair against that drive may be more successful than running it against the emulated drive and it would not hurt to try this. Hopefully at this point the drive in question is showing up under Unassigned Devices? You could also try and mount it from there and see if it can be mounted by UD. If you go through the rebuild route you will end up with exactly what is showing on the emulated drive (i.e. the big lost+found folder).

Seems unlikely to me but if you are running off another flash drive then just check your share settings look as expected. It might be worth trying \\ip-address\sharename type format and see if that works. Could also be worth rebooting the windows machine before doing that to make sure there is nothing lingering on the Windows side.

That implies a mis-configuration of emby. Any idea why emby is configured to give it access to /mnt on the host in the first place as this seems unusual. The location /mnt/videos it is creating is only in RAM so it’s contents are lost on reboot. It might be worth asking in the emby support thread if you are not sure.

Have you tried something like VLC that can play most video files directly off SMB shares. I personally use inFuse to play files off my server but that does have a subscription cost associated with it.

That suggests a potential problem with name resolution. Does it work if you use the servers IP address rather than its name? I always find this tends to be more reliable on Windows.

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

There is not much that can go wrong as long as you are in the config/shares folder on the flash drive. Even if you delete the wrong one then Unraid would automatically recreate one as soon as it finds a top level folder on the main array or a pool corresponding to a share. The fact that you have all those superfluous ones suggests at some time in the past you accidentally created top level folders with those names, but have subsequently tidied things up.

There should be an entry in the syslog every time such a notification is generated and I did not see any. Which is very strange. Any chance of enabling the Testing mode of logging in the plugin settings; waiting till you get more occurrences of the notification; and then posting your diagnostics. That would allow me to confirm what is happening under the covers.

This is already planned for the 6.13 release when the requirement for the main Unraid array is removed.

Doing that would have removed files docker was trying to use such as docker.img which is in the ‘system’ share. I think you are going to have to force a shutdown by holding down the power button.