itimpi

Those two paths are just different views of the same file(s). It is just that the /mnt/user one goes through the Unraid Fuse layer that handles user shares (which means any files on array drives or other pools are also included) and the /mnt/cache one bypasses it going directly to the cache drive showing just what is on the 'cache' pool.. There is no file movement involved.

The difference is just a few seconds during the bot sequence. The rest of the time there will be no noticeable difference, and USB2 has proved more reliable than USB3. It would not hurt to have a spare ready but no rush to replace the current flash drive if it keeps working. Just make sure you have a backup (particularly of the config folder) in case the current one ever fails.

Easiest is to have the Unassigned Devices plugin installed (to handle mounting the USB) and Dynamix File Manager plugin (to handle copying files to/from the USB).

This suggests failing drive as the USB stick is formatted as FAT32 (which Windows should be happy with) when working normally. All settings are saved in the config folder, so if you copy it onto a new flash drive your settings should all be there. However when creating the new flash drive I would first check it boots OK in case some of the settings in the config folder got corrupted and later cause problems when booting after you overwrite the default settings with your specific ones.

That syslog snippet suggest a connection problem on the drive in question as it is taking continual resets to get a transfer to complete correctly.. Typically due to cabling (either SATA or power).

Those are not the diagnostics which downloads as a single zip file. You need to post that instead of the contents of the zip as individual files. Maybe your system is trying to be ‘helpful’ and automatically opening the zip file and showing you the contents.

With the 6.12 release you need to include the partition number (I.e. /dev/md3p1 instead of /dev/md3).

It might be worth running a check filesystem on all array drives and pools in turn. I have seen file system corruption causing problems with shares.

NO! If they were root they would not be visible over the network.

You need to remove the -n option or nothing will be fixed. If xfs_repair asks for it use the -L option.

Have you tried running Tools->New Permissions against the share in question?

You could try the Factory Reset plugin.

If you are sure the disk is XFS format, then with the array stopped you can click on it on the Main tab and explicitly set the format to xfs. When you now start in Maintenance mode you will offered the option to run xfs_repair via the GUI.

You can use the steps detailed here in 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.

You can always use the Manual method described here in the online documentation.

This is covered here in 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.

The first step would be to replace the existing parity1 drive with 1 of the 12TB drives and rebuild parity on that drive. you mention replacing some of the other drives, but perhaps you should clarify exactly what mix of data drives you intend to end up with in the array.

Unraid has no WiFi drivers.

You cannot copy data to the drive outside Unraid without invalidating parity. However as long as the drive was formatted by Unraid then you can copy data to it outside Unraid as long as you later use the New Config tool to reintroduce the drive and then rebuild parity. if you say there may have been some confusion at the ‘Unraid level about what file system was on the drive then there are a couple of thing I would suggest trying: Stop the array. unassign the drive (if it is currently assigned) click on the emulated drive and explicitly set it to be XFS rather than Auto start the array to see if any data is now visible. The other thing to try while the drive is not in the array is to see if it can be mounted in the server using the Unassigned Devices plugin. If it can then you could do any copying locally within the server. You could either speed up the copying by removing the parity drive until copying finished, or (safer) keep the parity drive assigned and live with the slower copying to keep protected against any other drive having problems.

have not spotted anything obvious in the diagnostics Just to confirm that the IP address you are using for the server is 192.168.1.65 ? If you boot in GUI mode can you login on a locally attached monitor/keyboard What about going into the console and trying to ping your router and then your PC to check they can be seen from the Unraid server?

If the reallocated sectors is not steady when they happen and continues to increase then the drive is unreliable.

Not quite sure what you have done with UFS Explorer? Did the UFS Explorer scan find anything? If so have you copied the files elsewhere if you want to put the drive back into the array?

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

these screenshots do not agree with the share configuration files are that are in the diagnostics. The configuration files in the diagnostics for those shares all reference a pool called ‘cache’.

There can also be an issue with a pin on a socket, or even just a badly seated cable. You get that symptom if there is no end-to-end connection on any pin on an Ethernet link. You would need to check the exact cable + sockets connection in some other way (e.g booting a different OS) to see if you get a different result. A software issue is unlikely I would think.