itimpi

This should be OK if you have both the Unassigned Devices and Unassigned Devices Plus plugins installed. Most likely issue is that you do not have the volume mapping for Krusader set up to allow access to UD disks. Posting a screenshot of the Docker settings for Krusader might help us determine if this is the case. You could also consider using the Dynamix File Manager plugin instead of Krusader for this - it can handle UD mounted drives as standard.

The server restarting by itself is nearly always hardware related with most likely culprits being thermal (e,g. CPU overheating) or PSU struggling. The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. 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.

It is up to the plugin developer to introduce such messages if they are needed. In most cases you can safely close the window when the Done button appears.

Handling of unmountable drives is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

Those permissions are definitely wrong. Not sure what could be setting the permissions wrong at the /mnt level as those are set up dynamically when Unraid boots as I would have thought should be the ones at the /mnt/user level. However you could run the New Permissions tool against User Shares at that level to see if it changes things. If it does you will need to identify what could have set the permissions wrong in the first place to stop it happening again.

You tend to get that type of message any time a docker starts. If it keeps happening you probably have a docker crashing and then attempting to restart. You should be able to tell from the uptime which one(s) that is.

Not sure what to suggest then. The diagnostics that you posted show that you DID have a /mnt/user at the point they were taken. shfs 157T 43T 114T 28% /mnt/user0 shfs 157T 43T 114T 28% /mnt/user The system also seems to think all your shares are there: appdata shareUseCache="yes" # Share exists on disk1 D-----T shareUseCache="only" # Share exists on ubuntu domains shareUseCache="yes" # Share exists on disk1 I-O shareUseCache="only" # Share exists on ubuntu isos shareUseCache="yes" # Share exists on disk1 M---e shareUseCache="yes" # Share exists on cache, disk1, disk2, disk4, disk5, disk6, disk7 M----s shareUseCache="no" # Share exists on disk2 M---c shareUseCache="yes" # Share exists on disk9, disk10, disk11, disk12 system shareUseCache="yes" # Share exists on cache, disk1 u-----------------1 shareUseCache="no" # Share exists on disk1 VM shareUseCache="only" # Share exists on ubuntu, disk1 It just might be worth running a check filesystem on all drives in case there is file system corruption somewhere causing problems although I did not spot anything in the diagnostics. BTW: Not your current problem, but you normally want the appdata and system shares to be set up so that they are all on the cache to maximise performance of docker containers and to avoid keeping array drives pun up when not needed. Your current settings say move these to the array if possible.

In my experience they are fine for array drives which are mainly storing media (after initial load), but you probably do not want a SMR drive as a parity drive.

If you click on the Info icon at the top-right of the Unraid GUI does it show that IOMMU is enabled as this is required to pass through devices. If your system supports it then it is done via a setting in the BIOS.

You should reboot. This can happen if the process that supports User Shares crashes for some reason (not common, but not unknown). If that does not help for any reason then post back here.

If you want to continue using macvlan then you need to disable bridging on eth0 as mentioned in the Release Notes.

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

Unraid does not care where the drives are connected as long as they present their serial numbers (and size ) the same in both locations.

Earlier on you said these were to replace 2 existing drives so they were not additional drives but replacement drives. If so then it needs to be done in 2 steps

I think it should be 1,200 and not 1-200

Is this the rebuild onto the 10TB drive? If so I would not expect the rebuilt drive to have usable content.

That is what I would suggest. It seems unlikely multiple RAM sticks would go bad simultaneously so it can help with diagnosing whether you have a RAM stick problem or something else.

Even 1 error is too many. You could try running with less RAM sticks to see if that is any better in case the issue is the load on the memory controller.

Yes.

It one of the options on the Unraid boot menu. alternatively you can download the latest version from memtest86.com to make a bootable USB drive for that version.

Unraid only reads the SMART data when it thinks a drive that was previously spun down has just been spun up (typically due to it being accessed). The screenshots you posted from the Activity plugin have all been cur off to the right so no way to see what files/folders are being accessed to give a clue as to the culprit.

There are two problems with that: Identifying which part of the kernel has the problem and how it is triggered. I have no insight into this but I am sure if the culprits were known it would have been fixed long ago. Note that this issue is not Unraid specific - it can happen on any Linux system so if it were easy to do then it would already have happened. When you move to a new version of the kernel it is highly likely that old drivers/components will not even compile correctly.

Security considerations mean that shares are not exposed unless needed. The different values control visibility and access permissions required to access the share. The GUI built-in help gives more details as does this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

Have changed the SMB Export option for the shares you want visible on the network? The default is No which means they are not visible on the network.

Running the command du -h /var/log Should identify the culprit. if you have the Connect plugin installed then are you up-to-date as the last update fixed an excessive logging issue, and have you rebooted since then to reset the log space?