Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array


Recommended Posts

  • 2 weeks later...

Hi hoping someone can help

I have unassigned devices install and the addon and when I have plug my usb into the sever to transfer  movies over the only option I have is to format and I don't want to do that as the usb has all the movies already on it. how do I work around this?

ud.PNG

Link to comment
5 hours ago, topind said:

Hi hoping someone can help

I have unassigned devices install and the addon and when I have plug my usb into the sever to transfer  movies over the only option I have is to format and I don't want to do that as the usb has all the movies already on it. how do I work around this?

ud.PNG

Linux/Unraid does not recognize the file system on the disk.

Link to comment

Hi 

 

I have 12TB USB3 GRAID HDD ( 2x6TB) with HFS+ Format ( If you don't know what GRAID is please google it before lecturing me about how bad is RAID0 ... because this is not ) 

 

I hocked it to the server via USB3 and used Krusade to move the files and I was deleting the folders the I finished moving during the process.

suddenly Krusader couldn't delete files and folders from the drive....

 

Unraid still show it as Read & Write everywhere except when I used the terminal ( rm -f ) command on one of the files it gave that the drive is read only 

 

After searching the forum for two days I did all these solutions without any results :

 

1- Deleted Krusader 

2- Used the files manager to delete

3- Used the terminal to delete 

4- Rebooted the server 

5- Turned off docker 

6- Rebooted the drive 

7- Used "Fix common problems plug in" ( and the extended option too )

8- Changed the permissions to read only then back to read and write via the share page. 

9- Reapplied the permissions via the "new permissions" settings to everything on the server. 

 

The drive work normally on mac and on windows with mac addon .. and files can be deleted.

 

I'm using the latest unRaid 

Update 1 : Now it's working normally !!!!!! I didn't do anything !!!
Will update if it comes back again 

warmind-diagnostics-20220901-1615.zip

Edited by Thamer Alfuraiji
typo
Link to comment
On 1/18/2022 at 12:05 PM, dlandon said:

I'm finishing up a new feature that allows you to add an alias name to a disk device and then use that name to mount, unmount, and spin down a disk.  Using this feature, you can spin down a disk when it is unmounted by changing the device script like this:

  'REMOVE' )
    # do your stuff here
    /usr/local/sbin/rc.unassigned spindown name=Scratch

After the disk is unmounted the 'REMOVE' event is sent to the device script and at that time the spindown can occur.  The caveat is that this only works in 6.9 and later.

 

Here is a screen shot to show how the alias naming works.

2031750679_UDDisplay.thumb.png.800207c822bb94bbb5f195d7e9ac5e8f.png

 

Don't use the hdparm command on 6.9 and later because it confuses the spin down logic in Unraid.

 

Can we come back to this. It is not obvious to me what the correct method to remove a drive as safely as possible.

 

Can the current method be improved because you can clearly hear the drive head horribly clunking if you go directly from umount to power off?

 

There are many threads discussing this one is the most simple.

 

https://unix.stackexchange.com/questions/35508/eject-usb-drives-eject-command

 

(It is labelled USB the content quickly becomes more generic than that)

 

 

 

 

Link to comment
2 hours ago, NAS said:

Can we come back to this. It is not obvious to me what the correct method to remove a drive as safely as possible.

Unmounting the drive cleanly should be a safe way of removing it.

 

2 hours ago, NAS said:

Can the current method be improved because you can clearly hear the drive head horribly clunking if you go directly from umount to power off?

The spindown is not a power off command.  I've not seen any head clunking tbis with any of my drives.

 

Have you tried the commands in the link you supplied to see if there is a difference in the head clunking?  I suspect that the drive has an issue with parking the head cleanly.

Link to comment

I get these notification every hour (my smart poll time) in my logs.

 

Sep  4 11:01:03 SERV-X370 emhttpd: spinning down /dev/sdb
Sep  4 11:07:21 SERV-X370 emhttpd: spinning down /dev/sda
Sep  4 11:07:22 SERV-X370 emhttpd: read SMART /dev/sda

 

Both of these drives are SSDs that do not spin up.

 

Is there anyway I can turn spin up/spin down delay or even the smart polling time for Unassigned device SSDs? These settings exist for regular array devices but not for Unassiged Devices as far as I can tell.

Link to comment
44 minutes ago, sunbear said:

Both of these drives are SSDs that do not spin up.

Unraid 6.11 will spin down SSDs to put them in a lower power state.

 

If you don't want Unraid to spin them down, set your disks to never spin down, then set individual spin down times for the ones you want to spin down.

Link to comment
3 hours ago, dlandon said:

Unraid 6.11 will spin down SSDs to put them in a lower power state.

Ahh, okay. Well at least it's doing something.

 

Quote

If you don't want Unraid to spin them down, set your disks to never spin down, then set individual spin down times for the ones you want to spin down.

Okay, so there's not specific a setting for unassiged disk spin down?

 

In an unrelated note, I'm getting what seems like crazy read counts for one of my unassiged devices being passthrough to a VM. Does this seem abnormal to you?

 

Over a day or so, It's collected 18,446,744,073,709,551,616 reads as compared to the ~1,641,683,107 or so for my array drives. Meanwhile, it has only 2 writes?

Link to comment
1 minute ago, sunbear said:

Okay, so there's not specific a setting for unassiged disk spin down?

No.  UD disks follow the generic spin down timer.

 

2 minutes ago, sunbear said:

In an unrelated note, I'm getting what seems like crazy read counts for one of my unassiged devices being passthrough to a VM. Does this seem abnormal to you?

Over what tie frame were the writes?  Possible if the VM does a lot of reads?

 

Toggle to read/write rates and see if the VM is doing a lot of disk reading.

Link to comment
21 hours ago, dlandon said:

Unmounting the drive cleanly should be a safe way of removing it.

 

The spindown is not a power off command.  I've not seen any head clunking tbis with any of my drives.

 

Have you tried the commands in the link you supplied to see if there is a difference in the head clunking?  I suspect that the drive has an issue with parking the head cleanly.

 

As I understand it the spindown command above requires every device be given an alias. I have no doubt this works since spin state is easy to change I just question how practical it is to require that the user define an alias first and for every device.

 

For info this is not one specific drive, this is any spinning drive. It is easy to replicate, simply listen to the difference in sounds the drive makes between a spun down drive becoming unpowered and one that was just umounted and is still spinning.

 

I also understand that spinning down a drive is not the same as a power off command we are just mixing the terms because we are ultimately just taking about the same end goal, safe removal.

 

So to focus this a bit.

 

Currently the procedure for removing a drive is

  • umount
  • power off

I suggest there are more steps available to us:

 

  • umount
  • spin down
    • Other options to explore such as
      • eject/unbind the usb-storage driver/suspend the USB device
      • Offlining the device e.g. echo 'offline' > /sys/block/XXX/device/state ,

      • Detaching the device e.g. echo '1' > /sys/block/XXX/device/delete

  • power off

 

If we feel that these are too complex or risky we should at the very least offer a generic "safely remove option" that just spins down the drive without any requiring aliases etc. It is not really a "safe removal" when compared to similar features in Ubuntu etc but its far better than just removing power from a potentially spinning drive

 

TBH I think we can do much more here if we put our minds to it.

Link to comment
1 hour ago, NAS said:

As I understand it the spindown command above requires every device be given an alias. I have no doubt this works since spin state is easy to change I just question how practical it is to require that the user define an alias first and for every device.

The spin down command is done by Unraid and is done my passing in the devX designation given to the UD disk.  The devX designation can be used directly in the rc.unassigned script, or by using the alias.  When using the alias, UD does a look up of the devX designation for Unraid and then issues the spin down command.  The devX cannot be hard coded because it changes every time a disk is removed/installed.

 

1 hour ago, NAS said:

If we feel that these are too complex or risky we should at the very least offer a generic "safely remove option" that just spins down the drive without any requiring aliases etc.

Complex or risky is not the issue.  The issue is what makes sense for all situations.  I can look at doing a spin down without needing an alias if that is your concern.

Link to comment
2 hours ago, dlandon said:

...

Complex or risky is not the issue.  The issue is what makes sense for all situations.  I can look at doing a spin down without needing an alias if that is your concern.

I think if nothing else happens that one single enhancement would add a lot of value.

Link to comment
28 minutes ago, NAS said:

I think if nothing else happens that one single enhancement would add a lot of value.

 

Try these commands and see if it stops the spin down noises:

/usr/local/sbin/rc.unassigned spindown devX
echo 'offline' > /sys/block/sdX/device/state
echo '1' > /sys/block/sdX/device/delete

If it makes noises with the spindown command, try the other commands without the spindown.

 

When I tried this it spun down the USB device and then disconnected it from the server.  The only way it could be reconnected was unplugging and then replugging.  I never hear the sounds you are refering to, so I have no idea if this makes a difference.

  • Upvote 1
Link to comment
2 hours ago, dlandon said:

Try these commands

I've experimented with 

  echo '1' > /sys/block/sdX/device/delete

and it gave me a warm and fuzzy before powering off a device.  But sometimes I wanted to remount the device without unplugging it first.  However, it had disappeared completely.  Even doing an UD Refresh Disks wouldn't bring it back.

 

Research lead me to

  echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan

which was successful.  But there was no way to tell which bus the disk was on unless you noted it before the device delete.  If you implement the above, please include a way to bring back the disk.

  • Upvote 1
Link to comment
8 minutes ago, aim60 said:

I've experimented with 

  echo '1' > /sys/block/sdX/device/delete

and it gave me a warm and fuzzy before powering off a device.  But sometimes I wanted to remount the device without unplugging it first.  However, it had disappeared completely.  Even doing an UD Refresh Disks wouldn't bring it back.

 

Research lead me to

  echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan

which was successful.  But there was no way to tell which bus the disk was on unless you noted it before the device delete.  If you implement the above, please include a way to bring back the disk.

This is what my testing showed.  I'm not sure yet how I feel about how that works.

Link to comment
14 hours ago, aim60 said:

I've experimented with 

  echo '1' > /sys/block/sdX/device/delete

and it gave me a warm and fuzzy before powering off a device.  But sometimes I wanted to remount the device without unplugging it first.  However, it had disappeared completely.  Even doing an UD Refresh Disks wouldn't bring it back.

 

Research lead me to

  echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan

which was successful.  But there was no way to tell which bus the disk was on unless you noted it before the device delete.  If you implement the above, please include a way to bring back the disk.

 

This is good feedback and even better practical advice.

 

Obviously it is expected behavior needing to physically re-plug a device that has been fully removed although I admit is it not intuitive behavior. It does in my opinion reinforce the concept that a `warm and fuzzy` state exists below umount where the OS has released even more control of the device for safer removal.

 

We are in a strong position to cater for this unintuitiveness since we will know that the disk is still there and which bus it was on so in theory at least we can have a reattach button.

 

One unconfirmed edge case from udisksctl manpage

 

Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives.

 

I am unsure if this impacts the more specific block action, testing will tell.

 

I found linked via a previous suggestion this discussion discussing this approach on the Debian forums which is quite insightful.

 

 

Link to comment
6 hours ago, StevieZ said:

I have the same issue, i have an NTFS Disk I backed up all my data too from my Windows server but it doesn't show up in here? Anything i could be doing wrong? 

It's nothing you are doing wrong.  Windows server disks are partitioned in a way that Linux does recognize the file system.  If you can attach the disk to a computer and mount it, you can connect to it using a UD remote share to get at your data.  If you want it to be readable by UD, you'll need to remove the data and reformat it using UD.

Link to comment
3 hours ago, NAS said:

One unconfirmed edge case from udisksctl manpage

This command is not available in Unraid and I'm not keen on adding it.

 

3 hours ago, NAS said:

Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives.

If I implement a 'safely_remove' feature it will not be generic in the sense that it will not be done on every unmount.  The user will have to add a 'safely_remove' command, and only USB devices will be operated on.  You can appreciate doing a safe removal on a built in hard disk by accident.  A reboot would be required to restore it.

 

3 hours ago, NAS said:

We are in a strong position to cater for this unintuitiveness since we will know that the disk is still there and which bus it was on so in theory at least we can have a reattach button.

I'm not sure a re-attach is practical for UD.  Once a disk device is safely removed, it becomes a historical device and UD would have to track the device bus address and store it on the flash device.  Over the years, LT has stressed the need to reduce/eliminate flash writes.

 

The reattach idea, while seemingly a cool thing, is probably not a main stream need and removing and re-installing a USB device is not that much of an inconvenience for the few times it might be needed.  Also, if you think you might want to re-attach the drive without removing it first, don't do a safe removal command.  There is also the concept of auto mount.  The UD script would be run again and this might not be the desired action on a reattach.

 

This is the way I'm thinking about a 'safely_remove' command:

  'REMOVE' )
    # do your stuff here

    # Spin down disk - uncomment this if you want the disk to be spun down after the disk is unmounted
#   /usr/local/sbin/rc.unassigned spindown $DEVICE

    # Safely remove the disk - uncomment this if you want the disk to be detached after the disk is unmounted
#   /usr/local/sbin/rc.unassigned safely_remove $DEVICE

    /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Unassigned Devices" -d "Device unmounted" -i "normal"
  ;;

 

I've changed the spindown command to now use the /dev/sdX device designation as well as the alias so it can be used in the UD script without having to assign an alias to the device.

 

The same applies to the 'safely_remove' command.  You don't need a disk alias for the command to work.

Link to comment

Hello. This is probably a shot in the dark but maybe someone can help me. 

I use UD (& UD+) to mount my USB HDD on my unraid server and have it available via network share.

 

I use AutoIt3 scripts for moving some files back and forth from my windows machines to the server. I cannot write files to a UD mounted drive, when I copy a directory with autoit3 it will bring the folder but no subfolders and the function returns an error (no reason code). The same script targeting other unraid network shares has no such error and all files are properly copied. 

 

Checking the settings I did a bit of reading and tried turning on destructive mode but its still the same result. 

Link to comment
14 minutes ago, R0ME0 said:

Hello. This is probably a shot in the dark but maybe someone can help me. 

I use UD (& UD+) to mount my USB HDD on my unraid server and have it available via network share.

 

I use AutoIt3 scripts for moving some files back and forth from my windows machines to the server. I cannot write files to a UD mounted drive, when I copy a directory with autoit3 it will bring the folder but no subfolders and the function returns an error (no reason code). The same script targeting other unraid network shares has no such error and all files are properly copied. 

 

Checking the settings I did a bit of reading and tried turning on destructive mode but its still the same result. 

Post diagnostics file.  How are you referring to the disk device with Autolt3?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.