remotevisitor

Possibly a bug in samba for previously allowing access which has been fixed in the latest version.

Permissions on the directory don’t look correct, in order to enter a directory it should have the x (eXecute) permission.

Try find /mnt/disk* -name "Everest*" and see what it reports.

Use the Parity Check Tuning Plugin to schedule the check to only run when you aren’t streaming from plex (eg overnight).

In the past we have had reports on the forum of people "selling" on an Unraid system to another person. Sometime later, when the next release comes out, the buyer finds they cannot upgrade because the flash drive for their system has been blacklisted. The seller had used the mechanism for transferring the license to another flash drive which blacklists the flash drive that was sold.

See "No Key Transfers" in https://unraid.net/policies

I would try turning off the docker and VM service and see if it stops. Then at least you know it is something to do with them. if it still continues, try booting in Safe mode from the Unraid boot menu, which will not load any plugins. See if it now stops. if at any stage it stops it will then be a case of working through enabling your plugins/dockers/VMs to find which one is the cause. this number of writes to the flash drive is certainly not normal.

Does seam a bit strange . how about trying ‘lsof +D /boot’ to see what has any open files on the flash.

I would do an ‘ls -ltR /boot’ and look at the output to see what files have recently been changed to see if that gives any idea what might be writing to the flash drive

See last sentence in the UDMA CRC Errors section from the user manual. A link to the user manual can be found at the bottom right of the Unraid UI.

You have probably created the symlinks with absolute references which are only valid within the mappings provided inside your dockers. Lets say you are mapping /mnt/users/Media -> /Media in a docker. Now you create a symlink in the docker to be something like /Media/Favourites/A_Film -> /Media/Films/A/A_Film then this works fine within the docker because /Media/Films/A/A_Film is a valid path within the docker. But /Media/Films/A/A_Film is not valid outside your docker. If the symlink had been created with relative references like /Media/Favourites/A_Film -> ../Films/A/Favourites/A_Film this it would work both inside and outside the docker because inside it resolves to /Media/Films/A/A_Film and outside it resolves to /mnt/users/Media/Films/A/A_Film. You could work around the problem outside the docker by creating the symbolic link /Media -> /mnt/users/Media because then /Media/Films/A/A_Film would now be valid.

That error message is saying the directory that a symbolic link points at does not exists.

Look at using the rsync command with the -L option.

Did your problem go away with the latest version of the plug-in, or did your problem persist?

Should the online manual page linked to in the 1st posting be updated to include this —sparse option to save future users from the same problem?