The Dashboard is managed by Unraid.  UD only manages the Main/Unassigned Devices.  It is only a display issue.  it does not affect UD operation.

5 minutes ago, jake1239091 said:

rebooting my server

Try to mount it again then

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

57 minutes ago, jake1239091 said:

Attached is the Diagnostics file.

Your disk has a problem:

Dec  9 15:11:48 NAS unassigned.devices: Adding disk '/dev/mapper/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D'...
Dec  9 15:11:49 NAS kernel: usb 7-4: reset SuperSpeedPlus Gen 2 USB device number 2 using xhci_hcd
Dec  9 15:11:49 NAS kernel: sd 8:0:0:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
Dec  9 15:11:49 NAS kernel: sd 8:0:0:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f fc 08 00 00 00 08 00 00
Dec  9 15:11:49 NAS kernel: print_req_error: I/O error, dev sdf, sector 19532872712
Dec  9 15:11:49 NAS unassigned.devices: Mount drive command: /sbin/mount -o rw,noatime,nodiratime '/dev/mapper/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D' '/mnt/disks/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D'
Dec  9 15:11:49 NAS kernel: XFS (dm-3): Mounting V5 Filesystem
Dec  9 15:11:50 NAS kernel: usb 7-4: reset SuperSpeedPlus Gen 2 USB device number 2 using xhci_hcd
### [PREVIOUS LINE REPEATED 5 TIMES] ###
Dec  9 15:11:51 NAS kernel: sd 8:0:0:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
Dec  9 15:11:51 NAS kernel: sd 8:0:0:0: [sdf] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 02 80 00 9a 8a 00 00 08 00 00 00
Dec  9 15:11:51 NAS kernel: print_req_error: I/O error, dev sdf, sector 10737457802
Dec  9 15:11:51 NAS kernel: usb 7-4: reset SuperSpeedPlus Gen 2 USB device number 2 using xhci_hcd
### [PREVIOUS LINE REPEATED 5 TIMES] ###
Dec  9 15:11:52 NAS kernel: sd 8:0:0:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
Dec  9 15:11:52 NAS kernel: sd 8:0:0:0: [sdf] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 02 80 00 a2 8a 00 00 08 00 00 00
Dec  9 15:11:52 NAS kernel: print_req_error: I/O error, dev sdf, sector 10737459850
Dec  9 15:11:52 NAS kernel: XFS (dm-3): xfs_do_force_shutdown(0x1) called from line 1270 of file fs/xfs/xfs_buf.c.  Return address = 000000000e68283a
Dec  9 15:11:52 NAS kernel: XFS (dm-3): I/O Error Detected. Shutting down filesystem
Dec  9 15:11:52 NAS kernel: XFS (dm-3): Please umount the filesystem and rectify the problem(s)
Dec  9 15:11:52 NAS kernel: XFS (dm-3): metadata I/O error in "xlog_bwrite" at daddr 0x280008a4a len 8192 error 5
Dec  9 15:11:52 NAS kernel: XFS (dm-3): failed to locate log tail
Dec  9 15:11:52 NAS kernel: XFS (dm-3): log mount/recovery failed: error -5
Dec  9 15:11:52 NAS kernel: XFS (dm-3): log mount failed
Dec  9 15:11:53 NAS unassigned.devices: Mount of '/dev/mapper/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D' failed. Error message: mount: /mnt/disks/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D: can't read superblock on /dev/mapper/WDC_WD100EMAZ-00WJTA0_2YJ4RU7D. 
Dec  9 15:11:53 NAS unassigned.devices: Partition 'WDC_WD100EMAZ-00WJTA0_2YJ4RU7D' could not be mounted.

 

New release of UD:

- Beginning with 6.9, you can now spin up/down disks by clicking on the disk ball the same as array devices.

- Added a switch to show/hide Historical Devices.  Show all/none disk partitions has been moved to a UD Setting.

- Do some updates to status to background tasks to improve responsiveness.

@dlandon Is there a limitation of which drives actually support spindown? I have a Western Digital easyStore 4TB drive attached via USB and don't seem to be able to get it to spindown. Attached a screenshot and diagnostics. Around today if you need more data.

nyx-diagnostics-20201210-0750.zip

32 minutes ago, xaositek said:

@dlandon Is there a limitation of which drives actually support spindown? I have a Western Digital easyStore 4TB drive attached via USB and don't seem to be able to get it to spindown. Attached a screenshot and diagnostics. Around today if you need more data.

nyx-diagnostics-20201210-0750.zip 853.11 kB · 1 download

You'll need the next release of 6.9.

On 12/5/2020 at 11:23 AM, dlandon said:

The latest version of UD maps the remote shares to /mnt/remotes/.  You are encouraged to change your Docker Container and VM mappings to the new mount point.

 

If you can't do that, go the UD settings and set 'Legacy Mount Point Compatibility?' to 'Yes'.  Then unmount and re-mount the remote shares.  There will be symlinks created at /mnt/disks/ to the remote shares mounted at /mnt/remotes/.  You won't have to change any Docker Container or VM mappings.

What are remote shares, why would I want or not want them, and what might be the advantages of using the new system (and changing all my dockers and VM mappings) vs just changing to using the legacy mount point compatibility?

 

I've begun getting errors in the morning with "fstrim: /mnt/disks/Backup: FITRIM ioctl failed: No such file or directory"

 

the syslog has this line in it "Dec  9 14:57:35 media unassigned.devices: Successfully mounted '/dev/sdb2' on '/mnt/disks/Backup'."

 

I don't intentionally have any disk called backup, so I'm not sure what has caused this, nor exactly how to fix it.

 

Also, if the best practice is to change the docker and VM mountings to the new mount point, what exactly would that look like?  I'm really not sure what would need changed, so this is all very confusing to me.

 

thanks for any guidance!!

1 hour ago, JustinChase said:

What are remote shares, why would I want or not want them, and what might be the advantages of using the new system (and changing all my dockers and VM mappings) vs just changing to using the legacy mount point compatibility?

 

I've begun getting errors in the morning with "fstrim: /mnt/disks/Backup: FITRIM ioctl failed: No such file or directory"

 

the syslog has this line in it "Dec  9 14:57:35 media unassigned.devices: Successfully mounted '/dev/sdb2' on '/mnt/disks/Backup'."

 

I don't intentionally have any disk called backup, so I'm not sure what has caused this, nor exactly how to fix it.

 

Also, if the best practice is to change the docker and VM mountings to the new mount point, what exactly would that look like?  I'm really not sure what would need changed, so this is all very confusing to me.

 

thanks for any guidance!!

Disk devices will be mounted at /mnt/disks/.  Remote shares (NFS and SMB), will mount at /mnt/remotes/.  The are mounts of shares from a remote server or computer system.  Some users mount remote media for an app like Plex.  They would map the remote media mount point in a Plex Docker Container so it would be available to Plex.

 

You will have to provide your diagnostics before I could help with the fstrim issue.

1 hour ago, dlandon said:

Disk devices will be mounted at /mnt/disks/.  Remote shares (NFS and SMB), will mount at /mnt/remotes/.  The are mounts of shares from a remote server or computer system.  Some users mount remote media for an app like Plex.  They would map the remote media mount point in a Plex Docker Container so it would be available to Plex.

 

You will have to provide your diagnostics before I could help with the fstrim issue.

I appreciate the help.

 

I don't believe I need/want to mount remote shares.  The previous functionality was just fine, and I've not seen anything that makes me thing I need to change; other than the post I quoted, which seems to indicate I DO have to change something.  I don't know the benefits or disadvantages of using remote shares, or changing to use legacy (which is generally not the ideal solution to many issues I've dealt with in the past).

 

Assuming it's "best" to use the new system, it's unclear what exactly this means.

 

Quote

You are encouraged to change your Docker Container and VM mappings to the new mount point.

What new mount point, how does one set up this new thing, where and what exactly in Dockers and VM mappings needs changed??

 

I've attached the diagnostics, and again, very much appreciate your help making some kind of change, someplace, and understanding what that actually means.

media-diagnostics-20201210-0959.zip

25 minutes ago, JustinChase said:

I don't believe I need/want to mount remote shares.

Nothing you need to change then.

9 minutes ago, trurl said:

Nothing you need to change then.

It seems I'm being encouraged to do so...

 

3 hours ago, JustinChase said:

The latest version of UD maps the remote shares to /mnt/remotes/.  You are encouraged to change your Docker Container and VM mappings to the new mount point.

 

If you can't do that, go the UD settings and set 'Legacy Mount Point Compatibility?' to 'Yes'.  Then unmount and re-mount the remote shares.  There will be symlinks created at /mnt/disks/ to the remote shares mounted at /mnt/remotes/.  You won't have to change any Docker Container or VM mappings.

I only became aware of any of this when I started getting errors emailed to me yesterday, about /mnt/disks/Backup, which I never setup, and don't really understand.

 

I just want to get everything working again, the best way possible.

 

thanks

 

Meh, I just uninstalled Unassigned Devices for now.  Hopefully that fixes my errors.

Edited December 10, 20205 yr by JustinChase

1 minute ago, JustinChase said:

/mnt/disks/Backup, which I never setup

You have an Unassigned Device with NTFS filesystem mounted there. Are you saying you don't know you have an attached NTFS disk mounted?

11 minutes ago, trurl said:

You have an Unassigned Device with NTFS filesystem mounted there. Are you saying you don't know you have an attached NTFS disk mounted?

I never setup such a connection (that I remember), and do not have any disks physically located in that machine which are not assigned already. I only started receiving warnings about this location yesterday, after updating Unassigned Drives.  When I went to the plugin, I could see nothing there, as I no longer have any extra disks in that machine.

 

Given I have no extra disks, and currently have no need for unassigned devices, I removed the plugin, then rebooted, so I can't go check again.

 

Hopefully this removes this error, and if I ever need to use another device, I'm hopeful the UD plugin will guide me through this remote thing at that time.

 

thanks again for your help

I'm seeing this error text at the bottom of my screen with 6.9RC1.

 

Warning: Illegal string offset 'mountpoint' in /usr/local/emhttp/plugins/unassigned.devices/include/lib.php on line 176

 

 

nyx-diagnostics-20201210-1433.zip

37 minutes ago, xaositek said:

I'm seeing this error text at the bottom of my screen with 6.9RC1.

 

Warning: Illegal string offset 'mountpoint' in /usr/local/emhttp/plugins/unassigned.devices/include/lib.php on line 176

 

 

nyx-diagnostics-20201210-1433.zip 92.9 kB · 1 download

Update UD again.

I just released an update to today's release that will cut down on the slowness of UD in certain circumstances, and stop some of the time out errors in the log.  UD should be more responsive now.

11 minutes ago, dlandon said:

Update UD again.

I am on the 2020.12.10a release and the issue remains on both my unRAID 6.9 RC1 servers.

16 minutes ago, xaositek said:

I am on the 2020.12.10a release and the issue remains on both my unRAID 6.9 RC1 servers.

The message in the status line won't go away until you stop and restart the server.  Unraid will overwrite the status line message.  Or you can reboot the server.

8 minutes ago, dlandon said:

The message in the status line won't go away until you stop and restart the server.  Unraid will overwrite the status line message.  Or you can reboot the server.

Confirmed that took care of it!

With unraid 6.9 Unassigned Devices that are marked as passthrough now show their temp on the dashboard. Is it now possible to have it shown on the main page too? Read and write stats are showing on main now.

36 minutes ago, _rogue said:

Is it now possible to have it shown on the main page too?

Fixed in the next release.

After updating unassigned devices i get the following error on my radarr docker:

 

[Warn] RadarrErrorPipeline: Invalid request Validation failed:
-- Path: Folder is not writable by user abc

 

I've tried alot, which is noted here:

 

Radarr thinks he has no write access while it does · Issue #125 · linuxserver/docker-radarr (github.com)

https://github.com/linuxserver/docker-radarr/issues/125

 

Edited December 11, 20205 yr by Mirano

I am on the 2020.12.10a release and 6.9 RC1 and it seems that my QNAP share is not getting passed through to the Dockers. I can browse all the files like normal when clicking the mount point but for whatever reason dockers (including in the Docker config window within unraid) can’t see the files or the mount point. I tried reinstalling the plugin but had no luck.

38 minutes ago, Mirano said:

After updating unassigned devices i get the following error on my radarr docker:

 

[Warn] RadarrErrorPipeline: Invalid request Validation failed:
-- Path: Folder is not writable by user abc

 

I've tried alot, which is noted here:

 

Radarr thinks he has no write access while it does · Issue #125 · linuxserver/docker-radarr (github.com)

https://github.com/linuxserver/docker-radarr/issues/125

 

Read the recommended post at the top of this forum to see if that applies to you.

13 minutes ago, Whiskey90 said:

I am on the 2020.12.10a release and 6.9 RC1 and it seems that my QNAP share is not getting passed through to the Dockers. I can browse all the files like normal when clicking the mount point but for whatever reason dockers (including in the Docker config window within unraid) can’t see the files or the mount point. I tried reinstalling the plugin but had no luck.

Read the recommended post at the top of this forum to see if it applies to you.