On 8/11/2025 at 6:51 AM, dlandon said:

I am no longer working on this plugin. LT has taken over the maintenance and support. You will need to contact them about any issues or concerns you have. Future releases will come from them, and not me.

Copy that! My apologies, who is LT?

3 minutes ago, RockTheCatbox said:

Copy that! My apologies, who is LT?

Lime Technology.

3 hours ago, dlandon said:

Lime Technology.

🤦‍♂️ oh... Oops, yeah, haha... thank you!

Edited August 13, 2025Aug 13 by RockTheCatbox
To say thank you

running the 7.2 beta (not sure if it's relevant or not but may be):

seeing the unassigned devices plugin spam non stop request to the server to get updates, as soon as one finishes the next one starts. this isn't great for keeping the ui responsive (and low power devices can really struggle with this kind of behavior, especially since it seems to inject the response in the dom each time)

cleared the network stats once the page loaded to better show the behavior

Hi Unraid Community and LT,

I have a "generic" Micron 256gb SD NVMe drive that has Windows 11 installed. When I started my Unraid server install, booting from its USB, this drive would appear in Unassigned Devices, but could not be mountable. I need to put a fast cache drive on this Unraid box, and therefore bought a larger capacity Lexar NVMe SD drive and removed the old Micron one. Upon restarting Unraid, with the new NVMe and even without ANY NVMe in the slot, the old entry (assigned to sda), will not go away and my new NVMe isn't recognised.

This message persists, with or without a NVMe installed in the slot.

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Media removed, stopped polling

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

Seeking assistance, thanks in advance.

garagetp-diagnostics-20250816-1722.zip

Edited August 16, 2025Aug 16 by dartheejit

22 minutes ago, dartheejit said:

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Media removed, stopped polling

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

This is a card reader:

Aug 16 17:18:43 GarageTP kernel: scsi 0:0:0:0: Direct-Access Generic- SD/MMC CRW 1.00 PQ: 0 ANSI: 6

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0

Aug 16 17:18:43 GarageTP kernel: usb 1-10: new full-speed USB device number 6 using xhci_hcd

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Media removed, stopped polling

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

You can ignore that; if the new NVMe is not being detected, it suggests a problem with that device.

21 minutes ago, JorgeB said:

This is a card reader:

Aug 16 17:18:43 GarageTP kernel: scsi 0:0:0:0: Direct-Access Generic- SD/MMC CRW 1.00 PQ: 0 ANSI: 6

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0

Aug 16 17:18:43 GarageTP kernel: usb 1-10: new full-speed USB device number 6 using xhci_hcd

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Media removed, stopped polling

Aug 16 17:18:43 GarageTP kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

You can ignore that; if the new NVMe is not being detected, it suggests a problem with that device.

Thanks for the quick reply @JorgeB

I figured out that the issue was a Dell BIOS for storage, being set to RAID, rather than ACHI. I can now see the new NVMe SD device.

Though the pesky still persists : Unassigned Devices

sda	Generic-_SD_MMC_CRW_28203008282014000-0:0

Edited August 16, 2025Aug 16 by dartheejit

1 hour ago, dartheejit said:

Though the pesky still persists : Unassigned Devices

sda	Generic-_SD_MMC_CRW_28203008282014000-0:0

Post an actual screenshot, this doesn't show where it is. If it's in the historical section then it's normal as it'll remember every unassigned device that was connected. You can delete it from there. But what's the problem with it being there?

Edited August 16, 2025Aug 16 by Kilrah

1 hour ago, dartheejit said:

Though the pesky still persists : Unassigned Devices

See if you can unplug the card reader from the board; typically it connects to an internal USB header.

Hi,

i am using unassigned devices to create a root share (created via the option in the webui) of my storage.

now the problem: after every reboot the permissions of this share get reset, so my user can not access that share until i go into the ui and set them up again.

I tried reinstalling the plugin and recreating the root share. any pointers?

thank you in advance

EDIT:

the only message in the logs about the share

Aug 16 20:03:18 hal unassigned.devices: Warning: No valid smb users defined. Share '/mnt/rootshare/root.share' cannot be accessed with smb.

Edited August 16, 2025Aug 16 by sluggathor
EDIT: latest log after reboot

Have you set up the sharing in UD's settings? Without specifying a user for private, that message will appear.

I have this Error -> CIFS: VFS: cifs_mount failed w/return code = -22

But i dont find the Reason and Information to this and the return code= -22

I mount a Vu+ with SMB through the unassigned Devices to -> /mnt/remotes/VUSOLO2_Harddisk

Can you post your diagnostics

On 8/17/2025 at 4:26 AM, Squid said:

Have you set up the sharing in UD's settings? Without specifying a user for private, that message will appear.

all set up.

this is what it has always been set to:

and this is what comes up after reboot:

i swear it worked a while ago...

Hi there,

first off, thanks for creating and maintaining Unassigned Devices.

I’m trying to add an SMB share via an IPv6 literal. Using the UD wizard, discovery works: I can browse the server and see my shares over IPv6. However, when I click Apply, the entry in the UD table shows:

SMB //xxxx:xxxx:xxxx::abc/Share — Invalid Configuration — Remove and Re-add —

If I mount the same target from the Unraid shell, it works fine.

Example (works from shell):

mount -t cifs -o credentials=/root/.smbcred,vers=3.1.1,iocharset=utf8 //[xxxx:xxxx:xxxx::abc]/Share /mnt/remotes/Share

When I try the wizard with a bracketed literal like [xxxx:xxxx:xxxx::abc], it can’t resolve the address (No shares can be found).

Without brackets, the wizard can discover/browse, but applying the config still results in “Invalid Configuration”.

I must use the IPv6 address (hostname is not an option in my case).

Questions:

1) What is the correct syntax for IPv6 literals in UD for SMB targets?

2) Does UD fully support SMB over IPv6 for saved entries, or is this a known limitation/bug?

3) Anything I should set in the “Share IP/Name” field or mount options to make this work?

Thanks a lot for any guidance!

Add "Mount options" Field for Remote SMB Shares in Unassigned Devices

Hello Unraid Community & Support Team,

I am in the process of setting up a new Unraid server (currently on version 7.1.4) which will run a number of Docker containers that need to access a media library on a separate NAS via remote SMB shares.

The Challenge:

To ensure my Docker containers (running with a specific PUID/GID of 1000) have the correct read/write permissions on the remote media library, it is essential to add mount options like uid=1000,gid=1000 to the CIFS mount command.

Currently, the graphical interface for adding or editing a remote SMB share in the "Unassigned Devices" plugin does not have a visible field to add these custom mount options. The current workaround is to bypass the GUI and use a custom startup script, which, while functional, feels counterintuitive for a GUI-focused platform like Unraid.

The Feature Request:

I would like to formally request the addition of a text field to the "Edit SMB Share" window. This field could be labeled "Mount options" and would allow users to directly enter crucial options like uid=, gid=, noperm, iocharset=, etc., when defining a remote share.

Benefits of this Feature:

• Simplifies Docker Permissions: This would make setting up Docker containers that interact with remote shares dramatically simpler and would prevent a common source of file permission errors.

• Enhances GUI Functionality: It would bring the functionality of the remote share feature in line with the rest of Unraid's powerful, GUI-based management philosophy.

• Reduces Need for Custom Scripts: It would eliminate the need for users to create and manage command-line scripts for what is a very common and important use case.

Thank you for your time and for creating such a fantastic platform. I believe this feature would be a valuable addition for many users in the community.

Best regards,

Donald

How do I get rid of old smb shares still listed as available? I had to rename my MyCloud 8TB NAS and the two old names still show up.

The last name in the list of three is current, the first two are old names. I tried using Krusader to remove them, but it cannot.

Reason why they'd be in the folder picker is because they exist within /mnt/remotes/ Change all the references on your containers and then reboot

On 9/14/2025 at 11:40 PM, donglobal said:

Add "Mount options" Field for Remote SMB Shares in Unassigned Devices

I'll add it to the list. Won't be for a bit though, and initially at least I think it would be simply a way to manually edit / add to the smb config instead of a GUI per se.

15 hours ago, Squid said:

Reason why they'd be in the folder picker is because they exist within /mnt/remotes/ Change all the references on your containers and then reboot

That did it, thank you. I documented this for future reference.

@dlandon

Hello,

I’m using the Unassigned Devices plugin to mount remote SMB shares. I noticed an issue with the default CIFS/SMB mount behavior:

• Problem:
  By default, the CIFS client uses cache=strict. When transferring large amounts of data—such as backing up directories, copying large media files, or synchronizing datasets—the data is first written to local disk cache before being sent to the remote share. This can lead to very high local SSD write volume.

• Impact:

  • Significant wear on SSDs, especially small cache drives

  • Reduced efficiency for large file transfers

  • Potential performance degradation for the system

• Suggested Improvement:

  1. Add an “Extra Mount Options” field in the SMB mount UI so users can specify cache=none or other caching options.

  2. This allows direct writes to the remote share, bypassing local SSD caching while preserving other performance options (e.g., rsize, wsize).

  3. If a UI field is not feasible, allow extending mount options via the Device Script without bypassing the plugin’s mounting logic.

• Expected Benefits:

  • Reduce local SSD wear for large file operations

  • Allow users to choose the caching strategy based on use case

  • Improve the plugin’s usability for scenarios like backups, large file transfers, or remote dataset synchronization

Thank you for your work on this plugin! Adding cache control would make it much more suitable for high-volume data operations.

I am having an issue with all of my unassigned devices performing very slowly, mainly when docker containers access them.

I've got sata spinning rust, sata SSDs, and NVMEs and they all work at 4-8 MB/s read or write, sometimes.

Sometimes they perform as expected. I have disabled all dockers and VMs while testing this and the performance is consistently....inconsistent. Any ideas where to start troubleshooting?

The two Sata SSDs should be doing 400 MB/s +. While the NVME should be significantly higher, it's a MP600

root@Tower:/mnt/disks# for i in */;do dd if=/dev/zero of=$i/testfile bs=1G count=1 oflag=dsync;done
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.2462 s, 66.1 MB/s ####hard drive
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 10.3554 s, 104 MB/s#####SSD
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 10.219 s, 105 MB/s#####NVME
^[[B^[[B^[[B^[[B^[[B^[[B1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 27.6436 s, 38.8 MB/s####SSD
root@Tower:/mnt/disks# for i in */;do dd if=/dev/zero of=$i/testfile bs=1G count=1 oflag=dsync;done
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.8363 s, 67.8 MB/s   ####hard drive
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.82615 s, 109 MB/s#####ssd
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.10683 s, 118 MB/s####nvme
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.94185 s, 181 MB/s####SSD




Tower:/mnt/disks# for i in */;do dd if=/dev/zero of=$i/testfile bs=1G count=1 oflag=dsync;done
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 14.1906 s, 75.7 MB/s
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.44429 s, 114 MB/s
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.24646 s, 116 MB/s
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.43812 s, 440 MB/s

After a bunch of searching I am trying to move on from the rootshare under SMB from Spaceinvader as I found many errors relating to it in my logs. I am trying to use the Unassigned Device settings to make a rootshare after removing the code in my SMB settings but when I try to rename Shares-Pools to rootshare it does not work and gives me this error in my syslog but as far as I can tell I don't have that name used as I removed the script from the SMB setttings. I need to use the name rootshare as my VM that does the backups uses that drive mapping to do online backups using iDrive. I would hate to have to go through all the subdirectories and custom files to backup. Thanks

unassigned.devices: Error: Device '//TOWER2/mnt/user' mount point 'Rootshare' - name is reserved, used in the array or a pool, or by an unassigned device.

Why does umount of a device through Unassigned Devices take that long when the target device crashed?

1. Device is mounted (CIFS/SMB) in Unassigned Devices. I mount with the following UD command through User Scripts:
   /usr/local/sbin/rc.unassigned mount //192.168.178.101/disk1

2. Target system crashes.

3. I umount with the following UD command through User Scripts:
   /usr/local/sbin/rc.unassigned umount //192.168.178.101/disk1

4. UD issues the following command and uses lazy umount:
   Unmount cmd: /sbin/umount -t cifs -l '/mnt/remotes/192.168.178.101_disk1' 2>&1

5. Every single umount takes approx. 5 minutes even with lazy umount applied.

What might be the reason and what can I do to fasten that?

Thanks in advance.

On 8/13/2025 at 2:01 PM, AEnterprise said:

seeing the unassigned devices plugin spam non stop request to the server to get updates, as soon as one finishes the next one starts. this isn't great for keeping the ui responsive (and low power devices can really struggle with this kind of behavior, especially since it seems to inject the response in the dom each time)

Came here to say the exact same thing!

It continuously spam and i think even after some time crashes brave.

Came here to say the exact same thing! It keeps spamming every second and i actually think this is the reason why my Brave crashes after some time. I uninstall and everything is back to normal!

I read LT has taken over but not sure they are actively working on this or not. Would be awesome if this was part of Unraid itself. This is a very useful and pretty much must have feature.