itimpi

In your the syslog in the diagnostics I see errors like: Aug 11 03:40:31 Tower kernel: md: disk5 read error, sector=2932403328 Aug 11 03:40:31 Tower kernel: md: disk5 read error, sector=2932403336 Aug 11 03:40:31 Tower kernel: md: disk5 read error, sector=2932403344 Aug 11 03:40:31 Tower kernel: md: disk5 read when you try and create the share. This suggests a problem of some sort with dusk5. The SMART information for this drive indicates it is probably failing and needs replacing as it has large numbers of reallocated and pending sectors.

As always with UnRaid releases the answer is Soon

It could be but then I would expect you not to be able to write anything to the flash drive even when not using Unraid and I assume by reinit you meant rewrite its contents? Another possibility is a malicious actor. Do you have the flash drive set up to be visible on your local network? Do you have remote access to Unraid set up without using a VPN link which is normally a bad idea - using built-in WireGuard instead is the recommended approach?

The normally recommended (secure) way to access the Unraid GUI from outside the LAN is to use a VPN link and Unraid has WireGuard VPN support built in which makes it easy. You can also (optionally) set up the WireGuard link to allow access to any device on your LAN, not just the Unraid server. An alternative is to use the MyServers plugin which has remote access to Unraid as one of its features.

Did you use the -r option with the rm command?

The procedure you need is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI.

Edit the title for the first post in the thread to add SOLVED to the thread.

The fact that a drive has not been formatted is irrelevant to a parity check so it must have been something else. if you get similar symptoms make sure you capture your system’s diagnostics zip file (obtained via Tools->Diagnostics) and post them if you want any sort of informed feedback.

Glad to hear you got the music back. have you even got a lost+found folder (which would show up as a User Share of that name? You normally only get one if any corruption was such that a file can be recovered but it’s name cannot be retrieved. If you DO have a lost+found folder then sorting it out is a labour intensive manual process, and in such a case the Linux ‘file’ command can be useful to at least determine the content type (and thus file extension) for files that have lost their name.

Have you tried using the 'ifconfig' command to check that you have a gateway assigned on the 192.168.1.x subnet (it probably should be the address of the unify router)? Without that you will not be able to access anything outside that subnet.

The drive currently has a non-zero value for Pending Sectors which is not a good sign. However sometimes these can be false and get cleared when the sector is next written. Probably worth running an extended SMART test on the drive.

Have you stopped the array?

Most of the time it is easier to restore from backups (assuming you have them). if you DO want to sort out a lost+found folder then it is worth mentioning that the Linux ‘file’ command can be used to determine the file type (and thus typically file extension) for files that have lost their names.

Yes - the mdX numbers correspond to the diskX numbers that show in the Unraid GUI.

This is expected behaviour. A User Share will give a consolidated view of all top level folders (appdata in this case) on each drive in the array and any pools to give a unified view of the share across all drives. When you delete the folder from disk3 then if there is no ‘appdata’ folder yet created on cache the share will disappear. A point you may have missed is that when you change the Use Cache setting to ‘Only’ that applies to new files - not existing ones. The mover application takes no action on shares that have Use Cache set to ‘Only’ so any files/folders already existing on the array are left there. If you want mover to transfer files/folders for a share from the array to cache then you need the Use Cache=Prefer setting. This is explained in the help built into the GUI if you activate that.

The syslog in the diagnostics is full of messages of the form: Aug 9 22:18:32 Tower kernel: XFS (md5): Metadata corruption detected at xfs_buf_ioend+0x51/0x284 [xfs], xfs_inode block 0x11fe6e050 xfs_inode_buf_verify Aug 9 22:18:32 Tower kernel: XFS (md5): Unmount and run xfs_repair Aug 9 22:18:32 Tower kernel: XFS (md5): First 128 bytes of corrupted metadata buffer: Aug 9 22:18:32 Tower kernel: 00000000: 24 1a 9c 92 6d 85 ce 6d 6f 93 4c d2 44 fc dc 3b $...m..mo.L.D..; Aug 9 22:18:32 Tower kernel: 00000010: 98 25 67 cf 3f 77 ea c1 c5 b7 19 f8 16 ee f9 6f .%g.?w.........o Aug 9 22:18:32 Tower kernel: 00000020: 76 48 30 f5 c9 61 87 35 a3 da 2a ee a0 d8 92 c3 vH0..a.5..*..... Aug 9 22:18:32 Tower kernel: 00000030: cc 6c cd 9b 9b 53 a0 69 79 01 e4 94 72 d5 4f 37 .l...S.iy...r.O7 Aug 9 22:18:32 Tower kernel: 00000040: aa 93 9e 81 25 4c 5d dd d7 25 b1 ba 1c c7 68 6b ....%L]..%....hk Aug 9 22:18:32 Tower kernel: 00000050: 00 b6 ab b7 f7 3e 76 31 ad 48 42 a3 ae b1 05 df .....>v1.HB..... Aug 9 22:18:32 Tower kernel: 00000060: de da 64 5c 81 28 13 65 0b 6f 1f 49 78 a2 3e 33 ..d\.(.e.o.Ix.>3 Aug 9 22:18:32 Tower kernel: 00000070: b4 01 36 42 53 25 cc d8 e1 93 28 7f 0a 9c db 66 ..6BS%....(....f Aug 9 22:18:32 Tower kernel: XFS (md5): metadata I/O error in "xfs_imap_to_bp+0x5c/0xa2 [xfs]" at daddr 0x11fe6e050 len 32 error 117 which shows that you have file system level corruption on disk5. This is probably the cause of your symptoms. The procedure for checking and repairing file system issues is covered here in the online documentation that can be accessed via the ‘Manual’ link at the bottom of the Unraid GUI.

what happens when you try and change the Use Cache setting for that share to ‘only’ instead of ‘no’.

Go to Settings->Global Share Settings and check that User Shares are enabled.

This typically happens when you copy something locally within the server (e.g. using cp, mc, rsync or krusader container) rather than across the network and have not made sure to keep permissions unaltered. In such a case using Tools->New Permissions can correct the issue.

It can certainly happen i have also experience of a single port on the HBA becoming unreliable whatever 4 way cable is used.

It means you have connection issues of some sort, and although it can be the drive the vast majority of the time it tends to be the cabling to the drive (power or SATA).

Just worth pointing out that step 1) is unnecessary (unless you want to stress test the new drive) as building parity writes to every sector on the disk anyway.

The official online documentation on replacing disks is here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI. you are correct in that the Parity Swap procedure is not the one to use in your case.

Mover is nothing to do with Docker directly - it is controlled by the settings you have on User Shares. If you post you system’s diagnostics. Up file (obtained via Tools->Diagnostics) this will allow us to see what settings you have specified for your shares. In addition if you go to the Shares tab and use the ‘Computer All’ button it will show you how much of the share exists on various drives (you could post a screenshot of the result).

I have found that sometimes downloading the zip file for the release and extracting all the bz* type files overwriting the ones on the flash can help. It as though during the online upgrade the writing of the new files does not quite succeed error free and this approach fixes this.