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


Recommended Posts

30 minutes ago, dlandon said:

A cloud storage?  Has it worked before?  Did something change recently?

 

It seems to be taking more than 10 seconds to connect.  I would think 10 seconds is enough time.

yes cloud storage from strato - this is the first setup on unraid.


on another server (no unraid) I can simply mount the drive via smb.

on unraid it has not worked at all so far.

 

 

the "setup" of the drive works, but i can't mount it.
i found out that i can ping the server, but when i want to make a test connection to this server via telnet on port 445, i get no response - timeout.

 

on the non-unraid server this also works without problems.

but i don't know why there is a timeout, if something has to be enabled by iptables, i don't know enough about unraid.

 

 

image.thumb.png.1c4c99b44a1036e290dc33ca195ad03e.png

Link to comment
11 minutes ago, dlandon said:

When you mount the remote cifs device on another server, how long does it take to mount?

 

Can you show the mount parameters on the other server so I can see what might be different?

 

the command i use:

mount -t cifs -v -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,credentials='/tmp/stratocreds' '//CIFS.HIDRIVE.STRATO.COM/root' /mnt/strato

 

happens in under a second

Edited by Saw249
copypastaerror
Link to comment
8 minutes ago, Saw249 said:

 

the command i use:

mount -t cifs -v -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,credentials='/tmp/stratocreds' '\\CIFS.HIDRIVE.STRATO.COM/root' /mnt/strato

 

happens in under a second

Please try this.  I've added the uid and gid.  See if this causes it to not work.

mount -t cifs -v -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/stratocreds' '\\CIFS.HIDRIVE.STRATO.COM/root' /mnt/strato

 

Link to comment
4 minutes ago, dlandon said:

Please try this.  I've added the uid and gid.  See if this causes it to not work.

mount -t cifs -v -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/stratocreds' '\\CIFS.HIDRIVE.STRATO.COM/root' /mnt/strato

 

on non unraid it works fine. 

 

on unraid via ssh i get:

 

Quote

mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

 

dmesg->

Quote

[57684.742626] CIFS: VFS: Error connecting to socket. Aborting operation.
[57684.742630] CIFS: VFS: cifs_mount failed w/return code = -115

 

i would say, a timeout ? 
 

Link to comment
1 minute ago, Saw249 said:

i would say, a timeout ? 
 

Probably because it can't connect.  Failure code 115 is "Operation now in progress".

 

UD is able to ping the remote server.  That's why the 'Mount' button is active.  I read some comments about port 445 and firewalls using Strato.  You should investigate that.

Link to comment
3 minutes ago, dlandon said:

Probably because it can't connect.  Failure code 115 is "Operation now in progress".

 

UD is able to ping the remote server.  That's why the 'Mount' button is active.  I read some comments about port 445 and firewalls using Strato.  You should investigate that.

 

 

yes CIFS/SMB should communicate via 445. that's why i tried to connect via telnet using that port. which works on the non-unraid server. and not on the unraid server.  

 

i think it is not because of my firewall (because other computer is in the same network). i even enabled unraid as exposed host in the router for a short time. 

 

so i guess: unraid blocks port 445 for outgoing connection? but i have no idea about iptables. i have never touched it. i was hoping others have the same problems to mount external SMB's.

 

Link to comment
1 hour ago, Saw249 said:

i don't understand why it worked on server 1 and not on unraid. but after i disabled the "netbios" filter in my fritzbox. it works now without problems. 

UD goes through a sequence of SMB versions when mounting remote CIFS shares until the remote share mounts.  The idea is to mount the remote share with the most secure version of SMB the server will support.  The sequence is as follows:

  • No version specified.  The remote server will mount with the most secure SMB version it will support.  The idea is that the remote server will handle the SMB version setting on it's own.  Some servers insist on the SMB version being specified though.  This is controlled by a UD setting and can be disabled.  If it's not enabled in UD settings, this step is just skipped.
  • SMB v3.1.1.  This is a very secure version and offers some read/write speed enhancements.
  • SMB v3.0.  This is in case the remote server doesn't support v3.1.1, it will hopefully at least support v3.0.
  • SMB v2.0.
  • SMB v1.0.  If NetBIOS is enabled on the Unraid server.  If not, SMB v1.0 won't work.

SMB v1.0 is not very secure and is not recommended unless the remote server is very old and doesn't support newer versions of SMB.

 

The issue you had was that I changed the v2.0 to v2.1 and your ASUS router did not accept the v2.1.  It didn't mount with v1.0 because NetBIOS was disabled on the Unraid server.  This was fixed in a later release of UD.

 

SMB v1.0 won't work unless Unraid and the remote server both have NetBIOS enabled.

Link to comment

Hi @dlandon I'm using a MegaRAID 3108 adapter that I haven't used previously and it's behaving a bit different than my Areca RAID adapter in UD. I'm trying to understand why... mostly just because I want to have confidence in using the 3108 going forward.

 

First what is working... UnRAID detects and I can assign to array.the 3108 three RAID logical volume drives: sdt, sdu, sdv

 

When unassigned, the three logical drives don't appear in the UD list.

 

Any thoughts what it is about how these logical drives are defined that prevent UD from listing them?

 

 

 

 

 

Edited by Lev
Link to comment
9 hours ago, Lev said:

When unassigned, the three logical drives don't appear in the UD list.

You have sdv assigned to the array as a cache disk.  What I suspect is that UD sees all the disks as being the same serial number and since sdv is assigned to the array, UD doesn't recognize sdt and sdu as being unassigned.

 

Do this and let's see if this is the case.  Stop the array.  Unassign sdv as a cache drive.  Look at the UD page and see if UD sees the disks.  If it does, show a screen shot.  You can then assign sdv back to the array.

Link to comment
On 11/17/2021 at 6:05 AM, dlandon said:

You have sdv assigned to the array as a cache disk.  What I suspect is that UD sees all the disks as being the same serial number and since sdv is assigned to the array, UD doesn't recognize sdt and sdu as being unassigned.

 

Do this and let's see if this is the case.  Stop the array.  Unassign sdv as a cache drive.  Look at the UD page and see if UD sees the disks.  If it does, show a screen shot.  You can then assign sdv back to the array.

 

Screenshot attached. Unassigned - Cache Drive.png

 

Following your thinking, I thought I'd do a 'New Config' and get a screenshot of what appears in UD when there is no array defined. Screenshot Unassigned - New Config attached.

 

This helped find a new clue... there are six more drives went undetected by UD that I did not previously notice which had been assigned in UnRAID. Drives: sdd, sde, sdf, sdg, sdh, sdi This is visible in the screenshot.

 

So what's different about these 6 other drives? These six are SAS drives, that are passed thru the 3108 as JBOD drives.... same as the SATA drives also are passed thru the 3108 as JBOD drives. SAS vs SATA is the major difference in disk type. See attached 'lsscsi -g.png' for a picture to help illustrate.

 

Summary of UD behavior by Controller type:

 

MegaRAID LSI 3108

  • UD only detect SATA drives, passed thru as JBOD with this controller. Not detecting SAS or RAID volumes.
  • UnRAID detects all three types of drives as unassigned.

 

Areca 1883

  • UD detects all three types as unassigned.
  • UnRAID detects all three types as unassigned.

 

I'm back to wondering... what is the difference between UD's unassigned disk function in code, vs how UnRAID's function works in code to identify eligible disks the operating system has? For example, I noticed in the 'lsscsi -g.png' the VENDOR attribute is generic as 'ATA' for SATA, but for others it's not generic... SAS its 'SEAGATE' and for RAID its AVAGO. 

 

 

 

Edited by Lev
Link to comment

@dlandon I was curious if I switched back to the Areca controller, would anything in the lsscsi command stand out as a difference? Answer is no, unfortunately, I didn't find anything. But I took some screenshots so you can see how UD with the Areca controller behaves as expected, and same as UnRAID in this test scenario.

 

Remember all the of the drive locations will have changed since I moved the cables from the 3108 to the Areca, so just look for the six ST12000NM002G in the lists.

 

Also, this is to be expected but just in case you wonder why the 3 RAID volumes are not in the list. Instead the has the 6 HGST physical drives that were part of the RAID volumes that were created on the 3108. All normal behavior here.

 

 

 

 

 

 

 

 

Edited by Lev
Link to comment
3 hours ago, Lev said:

I'm back to wondering... what is the difference between UD's unassigned disk function in code, vs how UnRAID's function works in code to identify eligible disks the operating system has? For example, I noticed in the 'lsscsi -g.png' the VENDOR attribute is generic as 'ATA' for SATA, but for others it's not generic... SAS its 'SEAGATE' and for RAID its AVAGO. 

UD has to have unique serial numbers for each disk.  Your external drive bays are presenting disks with a common serial number.

Link to comment
57 minutes ago, dlandon said:

UD has to have unique serial numbers for each disk.  Your external drive bays are presenting disks with a common serial number.

 

Yes.... you're on to something here! lsscsi doesn't show serial numbers... I'm running the command udevadm now and finding some interesting differences in terms of how serial number are being reported between the SATA, SAS and RAID drives with the 3108 controller.

 

udevadm is showing that the SAS and the RAID volumes have their serial number named as 'ID_SCSI_SERIAL'  and the contents of the 'ID_SERIAL' align with what you said. I'm curious to check again on the Areca controller it's putting the serial number in 'ID_SERIAL', if so then that may explain it... I'll test and follow up.

 

SATA drive

E: ID_SERIAL=WDC_WD140EDGZ-11B2DA2_2CHHA9LP
E: ID_SERIAL_SHORT=2CHHA9LP

 

SAS drive

E: ID_SCSI_SERIAL=ZLW0XV610000C0348ZZZ
E: ID_SERIAL=35000c500ca42e0ab  <-- this is not the serial number
E: ID_SERIAL_SHORT=5000c500ca42e0ab

 

Link to comment

@dlandon Success! LOL... but with a twist! Had a breakthrough this evening in narrowing down why this is behaving as it is. Come with me on this journey 😀

 

I took a single drive, ZLW0XV9J, its physical serial number on the outside label, picture below that is used to make the following example easier to explain.

  • UnRAID can detect it when it's attached to the Areca or MegaRAID 3108 controller.
  • UD cannot detect it, after reboot, when attached to the MegaRAID 3108 controller
  • UD can detect it, after reboot, when attached to the Areca.
  • <the twist is coming!>
  • UD can detect it, when hot-swapped after reboot, from the Areca to the MegaRAID 3108 controller!

I can mount it, everything works as expected when the drive is connected to the 3108 after it's been hot-swapped from the Areca.

 

There's a difference in UD's drive detection code, starting in include/lib.php, between lines 1863 to 1902 is where *I THINK* explains UDs behavior. I hope I don't embarrass myself 🤦‍♂️ but few dare to read the code, but I do!

 

I say this because the drive attributes returned from udevadm are different depending which controller the drive is attached too, as you'll see. That initial creation of the array of unassigned devices seems to be the point of deviation.

 

Attached are the following details.

 

ZLW0XV9J.jpg - This is a picture I took of the physical drive label for helpful reference point.

SAS disk - Areca.PNG - This is ZLW0XV9J correctly identified in UD when attached to the Areca controller.

SAS disk - 3108hotswappedFromAreca.PNG - This is ZLW0XV9J correctly identified in UD after its been hot-swapped from the Areca controller to the 3108 controller.

3108 drives.PNG - Screenshot from system devices showing that the drive is attached to the 3108 after the hot-swap.

UDseesHotSwappedsasDrive.png - This is the money shot... ZLW0XV9J is visible in UD and UnRaid after it was hot-swapped from the Areca, but it's other 5 siblings (ST1200NM002G) are not visible in UD.

 

udevadm outputs files - I ran command "udevadm info --query=all --name=/dev/sdab" after each change to document how each controller was reporting the information. 3 .txt. files are attached with how that the output of whats being reported changes.

 

 

 

 

 

 

 

 

Edited by Lev
Link to comment

@dlandon please, can you help me with my script?

 

When I connect a backup device (HD), the backup is done normally.

When I connect another backup device, the label name isn't updated. So I need to restart my server to clean up the "temporary file", so the label updates.

 

Doubt: when I finish making the backup, do I need to clean up any temp folder in unraid? I believe that is the problem.

 

The error is attached.
This is my script: https://github.com/brauliobr/Unraid-Unassigned-Bkp/blob/main/script

This is my post about my script: 

 

 

img-unraid.jpg

Link to comment
28 minutes ago, dlandon said:

There is nothing you need to cleanup.  Someone else has posted something similar.

 

Post the complete diagnostics zip and I'll try to reproduce the issue.

I was the one who posted something like this lol
I still haven't been able to resolve it. But I've already verified that the problem is with the script I'm using.
Diagnoses attached. Tks

server-diagnostics-20211119-1344.zip

Link to comment
13 hours ago, Lev said:

I say this because the drive attributes returned from udevadm are different depending which controller the drive is attached too, as you'll see. That initial creation of the array of unassigned devices seems to be the point of deviation.

UD depends on the id that udev picks up.  UD uses the /by-id/ to determine what is in the array and what is unassigned and that becomes the id UD uses.

Link to comment
2 hours ago, Braulio said:

I still haven't been able to resolve it. But I've already verified that the problem is with the script I'm using.

You are using the environment variable $LABEL as if it is the $MOUNTPOINT variable at times.  The $LABEL variable is the physical label of the partition on the disk and may or may not be the $MOUNTPOINT UD is using.  Don't use it as the mountpoint /mnt/disk/$LABEL you will have issues because it is not necessarily the actual mountpoint.  UD will unmount /mnt/disk/$MOUNTPOINT.  The $MOUNTPOINT may not be the same as /mnt/disk/$LABEL.  The script that gets executed is defined in the UD settings for the device and may or may not be the $MOUNTPOINT or the $LABEL.

 

Don't do this:
 

	if [ ! -n ${MOUNTPOINT} ]; then
		MOUNTPOINT="/mnt/disks/${LABEL}"
	fi

when you mount it.  Let UD handle it.

 

EDIT: You can check to see if the disk is mounted with this:

if mountpoint -q $MOUNTPOINT; then

 

Edited by dlandon
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.