itimpi

Each transcoded file effectively IS a new file so the behaviour you describe is exactly what Unraid should do.    Probably the best thing to do is to make sure the Minimum Free Space for the cache is set to a value that will stop it over-filling, and then when the free space falls below that value Unraid will start by-passing the cache for new files/transcodes.  

The rebuild starts by replicating exactly the existing disk contents, and then when it completes that stage the file system is expanded to fill the whole disk.  It is possible that you may have to reboot to get the file system expansion to take place although in theory the reboot should not be necessary.

Have you checked that the Export option is not set to No on the shares as that would stop them being visible on the network.?
 
if the answer to the Export setting is Yes have you tried running Tools->New Permissions on a share showing no files to see if that fixes the issue?

The process for changing the flash drive 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.

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.
 

Have you actually formatted the data disk from the Unraid GUI using the format option on the Main tab?

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).

As long as each user had there own login then Windows should maintain credentials at the user level..
 
what is important is that you connect any private/secure shares before any public shares to ensure you are using the correct credentials.   Windows always re-uses the credentials of the first connection and if you then try and make a connection which needs different credentials will refuse to use any new credentials and always tells you the username/password is wrong.
 

That suggest the flash drive is not being found correctly in the later stages of the boot sequence.   It could mean the flash drive is failing, but often simply rewriting its contents can fix such issues.

This will be because Unraid is ‘emulating’ the missing drive using the combination of the other data drives plus parity drive.   When you put in a replacement for the drive what is showing on the emulated drive is what will be rebuilt onto the replacement dtive.

Good chance the error was a CRC error which indicates a connection issue caused a failed transfer initiating a repeat,   Chances are you changing canoes has resolved the issue.  Since CRC errors are recorded on the drive and never rest to 0, if you click on the thumbs down symbol and select Acknowledge from the displayed menu Unraid will only warn you again if the value increases.   Occasional CRC errors are nothing to worry about but if they occur regularly you want to look into it as they slow down transfer speeds. 

I am not an expert on this, but should the exports not have a unique value for the -fsid option for each share?   The ones that you are saying are going wrong are where they have the same fsid value as another entry.

If you rename the folder on disk1 it will automatically become part of the Backup1 share..   This will happen even before you change the Included disks setting as that setting only applies to where New files go, not to reading existing files.

That is quite normal.   Rerun removing the -n option and adding the -L option.   If you then restart the array in normal mode I would expect the drive to mount OK.

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

The behaviour you describe sounds correct for the way that you have your system is currently set up.   You are trying to overload your pool capabilities.
 
A point to remember is that Minimum Free Space does NOT mean keep that amount of space free.   It is a value that when it drops below that the NEXT file to be created is sent to a different drive.   The current file will continue until it is complete which can take the free space well below the setting value..   That is why you want that setting to be larger than the biggest file you want to transfer.   Mover will not automatically move files off to get to the Minimum Free Space value.
 
It does not make sense to have Use Cache=Prefer for shares which total more than the available space.   You should either restrict this setting to those shares you really want on the pool and that will fit, or alternatively you can increase the size of the pool, or create additional pools.   Many people will have separate pools for caching, docker apps, VMs etc with each one using hardware and settings optimised for that type of use although there is nothings stopping you combining these functions onto a single pool.

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.

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.

Those diagnostics are full of read errors on disk2 and since there is no SMART report for that drive it has probably dropped offline.

If you are moving lots of small files (as if often the case for the appdata share)  then mover will be slow as there is a significant overhead per file for checks that mover does before it moves a file.  It can be faster to use something like Dynamix File Manager to move the shares from the cache to a specific disk,

Unassigning the drive would have exactly the same effect as physically removing it.  In both cases the drive will be emulated using the other drives plus parity.
 

The User Scripts allows you to run scripts at array stop/start/first start so you can easily make a custom script.
 
if you want to send a notification you can use the /usr/local/emhttp/webGui/scripts/notify command.   If you want to simply write to the syslog then you can call the ‘logger’ command.  Run either of these from a command line with —help to get the options supported.

Looking at the syslog in those diagnostics I see this:
Jun 17 22:18:50 T2 emhttpd: shcmd (2956): /usr/local/sbin/mover &> /dev/null & Jun 17 22:18:50 T2 kernel: shfs[29898]: segfault at 0 ip 000055d7967cb59c sp 0000151246774810 error 4 in shfs[55d7967c9000+c000] Jun 17 22:18:50 T2 kernel: Code: 48 8b 45 f0 c9 c3 55 48 89 e5 48 83 ec 20 48 89 7d e8 48 89 75 e0 c7 45 fc 00 00 00 00 8b 45 fc 48 63 d0 48 8b 45 e0 48 01 d0 <0f> b6 00 3c 2f 74 4d 8b 05 67 dd 00 00 85 c0 78 39 e8 9e da ff ff which indicates that the shfs process used to support User Shares immediately crashed when mover started - no idea why.
 
The good news is that restarting the server will get all your shares back as they were.
 
You could manually move the files from the drive on the array on to the pool to bypass mover if needed.

Have you checked for a folder called ‘appdata’ even if it is empty?   If it is empty then you can simply delete it.

Parity drives have no file system, and also do not need pre-clearing (except perhaps as a stress test) as building parity overwrites every sector on the drive.