remotevisitor

The main problem is that you have spelt most of the folders with "Sesaon" rather than "Season" rather than permissions, which is why you cannot find the expected folders.

When you move the license to a new flash drive, the old flash drive GUID is added to the blacklisted drives which will be included in the next Unraid update. This therefore disables the old drive in subsequent releases of Unraid.

Did the test duplicate file that you created exist in the same place on different disks. So if you have a duplicate file at /mnt/disk1/TV/series/file and /mnt/disk2/TV/series/file (just the name has to match, not the contents) then this script will report it as a duplicate. This often happens if you re-organise the data in a share by copying rather than moving the files between disks. As the contents of the 2 disks in the above example would be merged together under /mnt/user/TV to create the TV share only one version of the file will be visible at /mnt/user/TV/series/file, which is why it is useful to identify which files are duplicated and remove the duplicate. i suspect that you were expecting it to report files which have the same name and/or content in random locations .... unfortunately this script does not address this problem.

Did you apply the work around Squid posted about 3 post back in the thread?

Unfortunately I know of no way to recover files which have been made zero length other than from backups. Is it possible that in the past you have ‘tidied’ up your share which involved coping/moving files between a user share and a disk share (either over the network or on the Unraid system itself)? Files being made zero size is a symptom of copying/moving files between user and disk shares if the destination is effectively the same location as the source and is why you should never copy files between user and disk shares (unless you really understand when it is safe to do so) and is why disk shares are now disabled by default to help avoid this problem when copying/moving files across the network (and the help text for enabling disk shares has a warning about potential data loss if you do enable them). Of course it is possible that something else caused the files to be made zero in size.

The symptoms reported imply that Unraid booted ok off the USB drive but the USB drive failed to be mounted on /boot. There are several this to check/try: - Can you confirm that the drive is formatted as FAT or FAT32. - If plugged into a USB 3 slot try putting it in a USB 2 slot if you have any.

Which Unraid license do you have? I suspect the Plus license. 9 data disks + 2 parity + 3 unassigned = 14 disks. The plus license only allows 12 connected disks (checked at boot time). If you have the Pro license then the problem is something else. Update: Ah, just realised from your description that your error is probably occurring during the Bios initialisation which is before Unraid gets in so is probably something else.

One thing to consider is whether any of the old shares that are being consolidated to a single share currently have different split levels set .... when consolidated they will all have to use the same split levels.

Sorry I didn’t follow up on this, was away from home on a flaky Wi-fi connection at the time...... have you managed to get it working in the mean time?

On the windows box what name does this command return: nbtstat -A 192.168.0.15

I suspect your windows box thinks the connection to your new virgin media router is a public network rather then a private network and therefore the windows firewall is blocking the SMB connection to your unraid box.

The actual drive 12 being red-balled is to be expected at this point as it has not been rebuilt. if unraid also reported disk 12 as unmountable at this point when you tried to start the array, it indicates file system corruption on the emulated disk and as you don’t mention you took any action to correct this then only way you could have started the array is to check the box to tell it to format the (emulated) drive. If this is what you did, this is when your files were deleted.

You mounted the disk onto the directory /x, so the files will be in the directory /x.

I assume at step 4 you started the array. By any chance was there a warning that disk 12 was unmountable at that point?

Because if you had accidentally done the actions that Squid thinks you did (but you didn’t’t quote in your reply) then by the time you did the disk rebuild you had already erased all the files on the emulated failed disk by the format; therefore the disk was rebuilt with with all the files erased.

Suggest you have a look at the unBalence plugin as it does exactly what you want.

Possibly somewhere like the UK where all plugs contain a fuse (usually 1A, 3A, 5A or 13A, appropriate for the device using the plug) as well as the whole electric circuit having a breaker in the distribution unit.

Does your unraid server have an attached screen and keyboard, or is it running 'headless'?

Is the putty session still running ? if yes, is it's current directory on a mounted disk? if yes then that will be preventing the disk to be unmounted.

There was a similar case reported a few weeks ago. in that case the cache drive was btrfs and switching it to XFS solved the problem. i assume your cache drive is btrfs as it is the default for the cache drive,. You could try converting it to XFS and see if the problem goes away.

The lockup is not normal and as has been mentioned hopefully someone can help you diagnose the likely cause. I've not had any experience with lockups so you need someone more experienced than me in this area. Did the config report the parity drive as "missing disk" (i.e. it thinks there should have been a parity disk but could not find it), or did it report it as "unassigned" (it didn't think there should have been a parity disk present)? You did say that this was your parity drive .... and as such a parity disk does not usually have any file system on it. However in your case I suspect you were trying it with just a single data disk in which case it is the special case where the parity should be an exact copy of the data disk (which is why it possibly looks like an xfs file system). When you say 1000+ bad sectors are you talking about hardware errors reported when reading the disk, or just blocks in the xfs file system that are not correctly allocated? When building parity you may think it is does excessive read/writes, but disks are designed to read and write data and building/checking parity is about the less stressful read/write sequence that a disk can do as it is just serially stepping through all the tracks of the disks (i.e. it is not doing lots of random disk head movements). However the one thing that it does do special is read or write every sector of the disks; therefore if you have sectors on a disk that have a problem it is likely to make you aware of them. When I first started using Unraid I used existing disks from previous systems, which I believed were perfectly fine. However I soon found there were a few of the drives that actually had bad sectors on them of which I had been completely unaware. Luckily, because Unraid highlighted the fact that the disks had problems I was able to replace the problem disks while they were still under warranty. If you really do have physical bad sectors on the disk, then hopefully you will be able to get the disk replaced under warranty (hopefully your warranty on it is 2+ years as you said it was a year old) ... yes it is inconvenient to do a warranty replacement .... but much better to find out now about a problem disk before trusting important data to the disk or finding out after the disk is out of warranty. As has already being suggested, providing the diagnostics.zip file will allow people experienced in analysing the logs and configuration file to possibly help you.

From some of the issues you reported (1, 3, 7, 8 ) it looks like your USB flash drive has dropped offline for some reason; the issues you reported all look like issues reading or writing configuration information on the flash drive. initial suggestion is try moving the flash drive to a different USB slot. If it is in a USB3 slot and you have a USB2 slot available then try using that one.

Try booting into safe mode (which does not load any plugins), from the boot menu, and see if SMB works ..... The last time I saw a user having strange problems with SMB not working it was due to a plugin loading a different version of a library than what was in the base OS. Also if you have anything added to your go file try commenting it out.

I sounds like you have a file of the same name on 2 different disks involved in the share. do the VMs read/write to the share or to a data/cache disk involved in the share?

2 issues that you should change on your TV shows share settings.... But I am not sure they are causing your problem ... Set the minimum free space .... The usual recommendation is 2 times the size of the largest file you expect to write to this share. Use 'Included disk(s)' or 'Excluded disk(s)' but not both at the same time .... Decide which one you want to use and clear the other one.