dlandon

There is no 6.12 alpha. The beta testing is internal right now. I know there is a strong desire to get zfs integrated into Unraid, but the implementation of zfs is still in its early stages and is not ready for any public testing. There are also issues showing up with the upgrade to php 8 and plugin authors will have to make changes in their plugins. Some of the php upgrade issues prevent plugins from running at all. You will just have to be patient until it is ready.

Post diagnostics.

I'm not sure. The issue with a zpool disk is the zpool signature that is probably left on the disk.

The disk and partition have separate entries. The partition is the one with the -part1 at the end.

Go to a command line and do the following commands and post the results: zpool import -d /dev/sdX and zpool import -d /dev/sdX1 Where sdX is the device designation.

Post diagnostics.

In working with the zfs feature comming in 6.12 and doing some testing, it seems UD is not clearing off the zfs signature correctly on a zfs formatted disk. I'm looking into a solution.

Your disk appears to not be cleared of the previous ZFS file system: Jan 29 19:48:07 Gringotts unassigned.devices: Reload partition table result: /dev/nvme0n1: re-reading partition table Jan 29 19:48:07 Gringotts unassigned.devices: Formatting disk '/dev/nvme0n1' with 'xfs' filesystem. Jan 29 19:48:07 Gringotts unassigned.devices: Format drive command: /sbin/mkfs.xfs -f '/dev/nvme0n1p1' 2>&1 Jan 29 19:48:07 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1 since it has a dos partition already Jan 29 19:48:07 Gringotts zed[4418]: zed_disk_event: Jan 29 19:48:07 Gringotts zed[4418]: #011class: EC_dev_add Jan 29 19:48:07 Gringotts zed[4418]: #011subclass: disk Jan 29 19:48:07 Gringotts zed[4418]: #011dev_name: /dev/nvme0n1p1 Jan 29 19:48:07 Gringotts zed[4418]: #011path: /devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:00.0/0000:03:00.0/nvme/nvme0/nvme0n1/nvme0n1p1 Jan 29 19:48:07 Gringotts zed[4418]: #011devid: nvme-CT500P2SSD8_2151E5F48096-part1 Jan 29 19:48:07 Gringotts zed[4418]: #011dev_size: 500106813440 Jan 29 19:48:07 Gringotts zed[4418]: #011dev_parent_size: 500107862016 Jan 29 19:48:07 Gringotts zed[4418]: zfs_slm_event: EC_dev_add.disk Jan 29 19:48:07 Gringotts zed[4418]: zfs_deliver_add: adding nvme-CT500P2SSD8_2151E5F48096-part1 (NULL) (is_slice 1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_pool: evaluating vdevs on ZFS50 (by devid) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B1PA0_9MGZE6PJ-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B1PA0_9MHUW33U-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B1PA0_Y5KUR3EC-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B1PA0_Y5KUR47C-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B1PA0_Y6GJNR7D-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev ata-WDC_WD140EDGZ-11B2DA2_2CGKS72N-part1) Jan 29 19:48:07 Gringotts zed[4418]: zfs_iter_vdev: no match (nvme-CT500P2SSD8_2151E5F48096-part1 != vdev (null)) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 29 19:48:22 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1p1 (in use by xfs) Jan 29 19:48:24 Gringotts unassigned.devices: Format disk '/dev/nvme0n1' with 'xfs' filesystem: meta-data=/dev/nvme0n1p1 isize=512 agcount=4, agsize=30524098 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 data = bsize=4096 blocks=122096390, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=59617, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Discarding blocks...Done. Jan 29 19:48:27 Gringotts unassigned.devices: Reloading disk '/dev/nvme0n1' partition table. Jan 29 19:48:27 Gringotts kernel: nvme0n1: p1 Jan 29 19:48:27 Gringotts unassigned.devices: Reload partition table result: /dev/nvme0n1: re-reading partition table Jan 29 19:48:27 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1p1 (in use by xfs) Jan 29 19:48:27 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1 since it has a dos partition already Jan 29 19:48:27 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1p1 (in use by xfs) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 29 19:48:30 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1 since it has a dos partition already Jan 29 19:48:30 Gringotts zed[4418]: zed_udev_monitor: skip /dev/nvme0n1p1 (in use by xfs) Try clearing the disk with UD by clicking on the rec 'X' next to the serial number to clear the disk. That should clear out everything.

Post diagnostics.

UD does the same thing. I wasn't sure how you handled a udev event. The only disk Unraid sees as unassigned in this case is the JMicron. UD looks up the disk configuration by the serial number of the disk. I don't see how UD can find the wrong one, unless the config file is corrupted in ram.

Can you think of anything the USB Manager could possibly do to confuse udev? I have no idea why udev would detect a removed device and report it to UD.

Keep the UD logging on until it happens again. This will show us better what is happening.

Maybe when disks are swapped quickly? Not giving enoough time for things to settle.

When one drive is removed and another added, Linux will assign the same sdX to the new drive. That's not a problem. I suspect that the usb manager may be causing this issue. It looks like ithe removed drive was found after it was removed and then the new drive. The removed drive was then auto mounted, and when the new drive was found, UD did not mount it because sdg1 was already mounted. I'm not familiar with how the usb manager works, but maybe @SimonF can offer some insight. You can track the udev discovery of disks and hotplug events to see what UD is presented by setting "Debug Log Level" in UD settings to "Udev and Hotplug". You can then see what udev finds and how it's being presented to UD.

Logs are stored on the flash drive (/flash/preclear reports/) and are only removed if the user deletes them. If you are using the preclear docker, the logs are not stored.

The recycle bin is setup to not save a zero size file and doesn't put it into the Recycle.Bin folder even though it shows in the log. Why recycle an empty file? So when testing, be sure the file you are deleting has contents.

Be sure your text file has at least a 1 byte length. A zero byte file will not be put into the recycle bin.

Cables? Try USB 2.0 ports. Check BIOS for legacy USB support.

Your disk is dropping off-line or is being removed before it is unmounted: Jan 24 16:51:27 LunaServer ntfs-3g[13140]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: Failed to read vcn 0x0 from inode 5: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: Failed to read vcn 0x0 from inode 5: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: Failed to read vcn 0x0 from inode 5: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Jan 24 16:51:27 LunaServer ntfs-3g[13140]: Failed to read vcn 0x0 from inode 5: Input/output error Jan 24 16:51:27 LunaServer kernel: Buffer I/O error on dev sdf1, logical block 36, async page read How is it connected?

The device script "/boot/config/plugins/unassigned.devices/packages/" is a directory not a script file. This is the script that is executed when the device is auto mounted. The User script is the script that is tracked to show the "Running" condition when it is run in the User Script plugin. Click on the 'Help' icon in the upper right part of the page and read the help script - the question mark in the circle.

Post diagnostics.

Yes. Please answer my question about an error message or blank screen when you try to access the GUI. You should try to starting from scratch. Delete the Docker Container, delete the appdata/LogitechMediaServer folder and start over. Be sure to watch the log and wait for the Start Logitech Media server message before stopping it.

I'm trying to understand why a first time setup is having issues. In the meantime, I've found that you can stop and restart the docker and it will settle down and you'll be able to access the web page.

I just fired up a new LMS Docker from scratch and there is an issue with the WebGUI pn an initial install. I updated the Docker and it seems to work now. I'll do a bit more testing and put out an updated Docker if it tests out.

Do you get an error message when you try to access the GUI?