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

[almulder 21]

So I have upgraded to Beta 35 and was transfering some files from a drive via krusader with the drive being mounted via unassigned devices. and that worked great. unmounted the device added more files to the drived from another pc, re added the drive to unraid and it shows up in unassigned devices, but when I click mount it tries and the just come back to the option to mount. 

 

I have tried this with several drives. the can connect the firast time, but once unmounted and removed I and then re added it cant be remounted. 

 

This is what the log shows when tryiong to remount a drive again

Nov 20 13:09:49 TOWER unassigned.devices: Adding disk '/dev/sdn1'...
Nov 20 13:09:49 TOWER unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdn1' '/mnt/disks/WD_easystore_264D'
Nov 20 13:09:49 TOWER kernel: XFS (sdn1): Filesystem has duplicate UUID 4e86ed38-0af8-4794-9635-dd5554fa7f1a - can't mount
Nov 20 13:09:49 TOWER unassigned.devices: Mount of '/dev/sdn1' failed. Error message: mount: /mnt/disks/WD_easystore_264D: wrong fs type, bad option, bad superblock on /dev/sdn1, missing codepage or helper program, or other error.
Nov 20 13:09:49 TOWER unassigned.devices: Partition 'WD easystore_264D' could not be mounted.
Nov 20 13:09:49 TOWER unassigned.devices: Issue spin down timer for device '/dev/sdn'.

 

[dlandon 568]

6 minutes ago, almulder said:

So I have upgraded to Beta 35 and was transfering some files from a drive via krusader with the drive being mounted via unassigned devices. and that worked great. unmounted the device added more files to the drived from another pc, re added the drive to unraid and it shows up in unassigned devices, but when I click mount it tries and the just come back to the option to mount. 

 

I have tried this with several drives. the can connect the firast time, but once unmounted and removed I and then re added it cant be remounted. 

 

This is what the log shows when tryiong to remount a drive again

Nov 20 13:09:49 TOWER unassigned.devices: Adding disk '/dev/sdn1'...
Nov 20 13:09:49 TOWER unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdn1' '/mnt/disks/WD_easystore_264D'
Nov 20 13:09:49 TOWER kernel: XFS (sdn1): Filesystem has duplicate UUID 4e86ed38-0af8-4794-9635-dd5554fa7f1a - can't mount
Nov 20 13:09:49 TOWER unassigned.devices: Mount of '/dev/sdn1' failed. Error message: mount: /mnt/disks/WD_easystore_264D: wrong fs type, bad option, bad superblock on /dev/sdn1, missing codepage or helper program, or other error.
Nov 20 13:09:49 TOWER unassigned.devices: Partition 'WD easystore_264D' could not be mounted.
Nov 20 13:09:49 TOWER unassigned.devices: Issue spin down timer for device '/dev/sdn'.

 

Go to the UD settings and you can change the UUID for that drive so it is not a duplicate.

[almulder 21]

Ok I went into settings and clicked chnage UUID and got the following in the log. (UUID not changed). Tried removing drive, the added it back and then tried to chnage uuid.

 

Nov 20 13:22:15 TOWER unassigned.devices: Changing disk '/dev/sdn1' UUID. Result: ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_admin. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

 

[dlandon 568]

On 11/20/2020 at 4:24 PM, almulder said:

Ok I went into settings and clicked chnage UUID and got the following in the log. (UUID not changed). Tried removing drive, the added it back and then tried to chnage uuid.

 

Nov 20 13:22:15 TOWER unassigned.devices: Changing disk '/dev/sdn1' UUID. Result: ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_admin. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

 

Click on the + icon to show the partitions, then click on the check mark to check the file system.  See if that doesn't fix the file system.

[dlandon 568]

New release of UD:

• Change mount point icons to something more meaningful.  A pencil icon will show when the mount point can be changed.  A file folder icon will show when the mount point can be used to browse the device.
• The mounting of remote SMB shares has been changed to first trying to mount the remote share without the protocol (vers=) being specified.  If that fails the mount protocol is specified in the following order - SMB3, SMB2, and then SMB1 (if netbios is enabled).
• Encrypted disks will show the file system when mounted.

[dlandon 568]

On 4/17/2020 at 4:11 AM, wuftymerguftyguff said:

Hi,

 

Thanks for your attention.

 

I understand but what I am seeing is slightly different.  Forcing smb v1 does not work either.

 

If there is ANY value in the vers= option then I can’t write.

 

If I take the mount command from syslog and just remove the vers option it negotiates the highest compatible smb version with the server and I can write.

 

Jeff

This was posted some time ago - sorry for the slow solution.  I have released a new version of UD that should solve this problem.  When a remote SMB share is first mounted now, the protocol (vers=) is not specified.  I'm finding that a lot of remote shares will mount this way and the server will determine the most secure SMB version.  If that fails, the SMB protocol is specified and another mount attempted in the following order - SMB3, SMB2, then SMB1 (if netbios is enabled).

 

Please update and try again.

[saber1 9]

I did connect an external USB-HDD via Unassigend Devices to my unRaid.

In the Settings i set "Spin down disks?" to YES.

Does this also apply to USB-Disks? My disk is always over 40° C...  

[dlandon 568]

49 minutes ago, saber1 said:

I did connect an external USB-HDD via Unassigend Devices to my unRaid.

In the Settings i set "Spin down disks?" to YES.

Does this also apply to USB-Disks? My disk is always over 40° C...  

Yes, but some USB disks won't spin down.

[CS01-HS 28]

The latest version won't mount my SMB1 share. I think it might not be passing sec=ntlm but I don't see a mount command in the logs. Any way to debug it?

 

I've tried removing/readding the share with Force all SMB remote shares to SMB v1 set to Yes (as I had it) and No, neither works.

 

[dlandon 568]

13 minutes ago, CS01-HS said:

The latest version won't mount my SMB1 share. I think it might not be passing sec=ntlm but I don't see a mount command in the logs. Any way to debug it?

 

I've tried removing/readding the share with Force all SMB remote shares to SMB v1 set to Yes (as I had it) and No, neither works.

 

Post diagnostics.

[CS01-HS 28]

3 minutes ago, dlandon said:

Post diagnostics.

Sure, thanks. There's a bunch of spam in my syslog from an incompatible docker, let me know if you want me to clean it up.

nas-diagnostics-20201123-1144.zip

[dlandon 568]

2 hours ago, CS01-HS said:

Sure, thanks. There's a bunch of spam in my syslog from an incompatible docker, let me know if you want me to clean it up.

nas-diagnostics-20201123-1144.zip 163.51 kB · 0 downloads

I found it.  Fixed in the next release.

[CS01-HS 28]

Nice, thank you so much.

Do you mind telling me how my diagnostics helped? Maybe a hidden UD log that might help me in the future.

[dlandon 568]

1 hour ago, CS01-HS said:

Nice, thank you so much.

Do you mind telling me how my diagnostics helped? Maybe a hidden UD log that might help me in the future.

This:

Nov 23 11:40:15 NAS unassigned.devices: Mount SMB share '//10.0.1.10/Data' using SMB1 protocol.
Nov 23 11:40:15 NAS unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=1.0,credentials='/tmp/unassigned.devices/credentials_Data' '//10.0.1.10/Data' '/mnt/disks/time-capsule'

It's missing 'sec=ntlm'.

[CS01-HS 28]

Ha! I saw that and thought "how could I miss that in the logs?" but I get continuous "bogus file nlink value" cifs errors with SMB1 so by habit I end every syslog tail with 

| grep -vi 'cifs'

which of course removes it. I'm glad my stupidity wasn't an obstacle. Thanks again.

[CS01-HS 28]

1 hour ago, dlandon said:

It's missing 'sec=ntlm'.

I updated, tested and confirmed it now passes that parameter but only if Force all SMB remote shares to SMB v1 = Yes. It doesn't pass it if it degrades to SMB1 after failing higher versions. Not a problem if that's by design.

Nov 23 17:59:31 NAS unassigned.devices: Mount SMB share '//10.0.1.1/Data' using SMB1 protocol.
Nov 23 17:59:31 NAS unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=1.0,credentials='/tmp/unassigned.devices/credentials_Data' '//10.0.1.1/Data' '/mnt/disks/time-capsule'

 

[dlandon 568]

1 hour ago, CS01-HS said:

I updated, tested and confirmed it now passes that parameter but only if Force all SMB remote shares to SMB v1 = Yes. It doesn't pass it if it degrades to SMB1 after failing higher versions. Not a problem if that's by design.

Nov 23 17:59:31 NAS unassigned.devices: Mount SMB share '//10.0.1.1/Data' using SMB1 protocol.
Nov 23 17:59:31 NAS unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=1.0,credentials='/tmp/unassigned.devices/credentials_Data' '//10.0.1.1/Data' '/mnt/disks/time-capsule'

 

I've updated UD and removed the force SMB v1 setting.  There is no reason for it any longer.

[b0m541 1]

Mounting remote SMB shares does not work for me in version 2020.11.23b 

I can create an entry fine, and while doing that it will show the available shares. After the entry is created the "mount" button is greyed out and cannot be clicked.

I did not find any messages relating that in the regular log files, maybe I looked in the wrong location.

This is a rather urgent topic for me, since I have several containers who use remote shares.

 

[dlandon 568]

Just now, b0m541 said:

Mounting remote SMB shares does not work for me in version 2020.11.23b 

I can create an entry fine, and while doing that it will show the available shares. After the entry is created the "mount" button is greyed out and cannot be clicked.

I did not find any messages relating that in the regular log files, maybe I looked in the wrong location.

This is a rather urgent topic for me, since I have several containers who use remote shares.

 

Post diagnostics and a screen shot of the remote shares.

[b0m541 1]

Wow that was fast. where to find the shares diagnostics?

Edited November 25, 2020 by b0m541

[dlandon 568]

1 minute ago, b0m541 said:

Wow that was fast. where to find the shares diagnostics?

Just happen to be sitting at the computer.

 

Tools->Diagnostics

 

In the future always post diagnostics to get you an answer quicker.

[b0m541 1]

Oh I see. No offense, that data is super privacy invasive and I do care about that.

Please let me know what exact files you need to see where the problem is, I might then as well be able to understand the problem on my own.

 

[dlandon 568]

Just now, b0m541 said:

Oh I see. No offense, that data is super privacy invasive and I do care about that.

Please let me know what exact files you need to see where the problem is, I might then as well be able to understand the problem on my own.

 

The diagnostics are anonymized.  If you feel they aren't enough, post a request to Limetech about your concern.  It can be difficult to help without diagnostics.

 

At least show me a screen shot.

[itimpi 839]

5 minutes ago, b0m541 said:

that data is super privacy invasive

It would be interesting to know what data you think falls into that category as it is meant to be anonymised.

[b0m541 1]

I saw that they are anonymized, I looked at them, and my concerns are still there.

The concept to post a complete set of diagnostics data publicly for anyone to read who desires to me is conflicting with the concept of data thriftyness. A request to Limetech will not resolve that conflict.

I honestly doubt that all that data will be necessary to actually find why the mount will not work.

 

I would assume it is also in your interest if users are willing to look into the problem on their own.

So if you let them know, where to look, where is the harm?

I understand that it will be a bit more effort on each side, but privacy has often a cost after all.