itimpi

Do you have the VM service enabled? Doing so will create the libvirt.img file regardless of whether you have yet created any VMs.

Parity never emulates 'files' - it emulates disk sectors with no understanding of their contents. The contents are interpreted at a higher level within the OS.

Note I said try disabling the docker service - not just the container to make sure. Do you lave other containers running - this is not something that can be seen from the diagnostics. Also it is possible that the docker service itself is doing something periodically even when idle. Yes. That was what made me immediately suggest docker (and containers) as the possible causes of the disk activity. BTW: I have no experience of that container so have no idea why you are getting that message logged. It makes me think something may not be set up ideally.

Looking at your diagnostics I would thing the activity is caused by your docker containers? Is the 'active' drive 'disk1' at the Unraid level as I see that both your docker image file and your appdata folder are currently on that drive. There are also lots of messages in the syslog relating to the 'paperless' container not connecting. You could check by stopping the docker service and seeing if that stops this disk activity.

You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

It is used to support running VMs.

What do you have for the Minimum Free Space setting for both the pool concerned and the Shares involved? You will get better informed feedback if you provide your system’s diagnostics zip file (obtained via Tools->Diagnostics).

You have to decide how you want the unRaid file system to be presented in Krusader. Many Krusader users will have mappings that might be something like: /mnt/user -> /media /mnt -> /drives /mnt -> /unraid In theory the second mapping includes the first and the third includes the other two but keeping them separate can be a good idea as it give you a good idea at what level you are currently accessing the Unraid file system

i have been working through all cases where this can happen in the code and I think I now have them all fixed in the version running on my test server. There was a number of places in the code where regressions had crept in as I tried to tidy up he code to make it easier to maintain. I have also been putting in some effort to make sure that notifications are more meaningful. I should be releasing a new version incorporating all my fixes (as well as new functionality) in the next few days.

I don’t see how as normally a docker container cannot access packages installed on the host.

You have no path mapping that points to /mnt at the Unraid level which is why you cannot see that level from Krusader.

That is not normally a good idea - robots are good for scanning for ports. the only secure way to access unRaid from the internet is to use a VPN and since unRAID has the WireGuard VPN software built in it is the recommended way to set up secure access to your server for remote admin.

Just be careful you do not end up getting problems due to your log filling up with mover messages.

Strange -I do not get that banner - I wonder why you do

Yes - but if the USB is not mounted then /boot is only in RAM.

You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post. Yes - mover is normally recommended simply because most people find it easier. However mover should have worked so whatever is stopping that might also affect a manual move.

I would suggest that you try plugging a monitor into the onboard graphics connector. It the board wants a monitor connected you can always buy an hdmi dummy plug

It gets cleared if you reboot the server.

When you say the “Shares Menu” do you mean the Shares tab in the GUI or something else? /mnt/user is just a combined view of all the top level golfers on all the disks. It might be worth running a file system chevk on each of your drives in case some corruption has occurred and is upsetting things.

I am not sure you will get consensus on this I personally prefer XFS because it seems to be more resilient to unexpected server crashes/power downs while others care more about the BTRFS ability to automatically detect bitrot.

Looking at the syslog you seem to be getting I/O problems reported on multiple drives. Since it happens on multiple drives it tends to point to something they share (e.g. disk controller, power).

Are you sure that you have removed the plugin? If you have then there should not be an entry in Settings.

Since the USB stick is booting fine on other machines it is obviously something specific to this one. I suggest you remove the trailing ~ from the uefi folder to see if you can boot in UEFI mode. Unraid licence keys are valid for all releases of Unraid so no problem doing this if you want.

Normally these checks only take seconds/minutes. What device name did you use? Getting the dots suggests that the master superblock was not found and a search is being made to try and find a backup copy.

I think you will find that over normal CIFS network shares you cannot see symlinks as being links (at least that is my experience). No idea if using NFS will give you what you wand.