1 hour ago, Splash said:

With the current mount attributes it is proving a warning due to not being able to update the file modification time. (futimens).

What warning are you seeing?  I don't see anything in the syslog.

There is no warning provided within unraid, the docker app is reporting that it is unable to set a modified time...

 

Is there an option to set the mounting attributes? Eg remove ,default_permissions,noatime etc

2 minutes ago, Splash said:

s there an option to set the mounting attributes? Eg remove ,default_permissions,noatime etc

No.

 

I'm trying to understand what the backup software is having trouble with so I can potentially change the mount parameters.  It looks to be with the atime and not mtime.

 

Mount the disk manually with this command line and see if the backup software works without the warning:

/sbin/mount -t 'ntfs' -o rw,relatime,nodev,nosuid,nls=utf8,umask=000 '/dev/sdm1' '/mnt/disks/Primary'

 

Note the 'relatime' option.

Let me give it a go with a manual mount 1 option at a time to see which one is triggering it.

 

 Thanks for the help!

7 hours ago, Splash said:

Let me give it a go with a manual mount 1 option at a time to see which one is triggering it.

 

 Thanks for the help!

I think you’ll find it’s the relatime option that will solve it.

Probably as I cant duplicate the error now that its updated the files.

Any thoughts on adding the option to modify the mount attributes?

2 minutes ago, Splash said:

Any thoughts on adding the option to modify the mount attributes?

This is not a good idea and will lead to more support as most users will not fully understand what the mount options do.  I'm going to change the 'noatime,nodiratime' to 'relatime'.  This should solve your backup software issues.

Awesome, appreciate the consideration! I guess you are right... 

Is it possible to build in a feature to hide any more than 5 'historical devices'?

 

I'm reluctant to 'remove' them as I may want to re-use a certain disk in future.

Edited September 8, 20232 yr by dopeytree

6 minutes ago, dopeytree said:

Is it possible to build in a feature to hide any more than 5 'historical devices'?

 

I'm reluctant to 'remove' them as I may want to re-use a certain disk in future.

There is a switch at the top of the UD page to hide all Historical Devices.  I encourage you to use that.

ace thanks

Hi everyone, 

 

I recently discovered and started using Unassigned Devices to mount my other unraid server's NAS volume as a remove share for Jellyfin. Everything was working fine until I had to shutdown and reboot my servers and now UD is won't mount my network share stating it is unavailable; and the mount button is greyed out and I cannot even try to click to mount it. 

 

What am I doing wrong? At first I thought it was because my remote share server started up later than the server that has UD installed on it but when I rebooted that server again thinking it would autoconnect after startup; it didn't. 

 

 

- Cheers,

4 minutes ago, resentedpoet said:

Hi everyone, 

 

I recently discovered and started using Unassigned Devices to mount my other unraid server's NAS volume as a remove share for Jellyfin. Everything was working fine until I had to shutdown and reboot my servers and now UD is won't mount my network share stating it is unavailable; and the mount button is greyed out and I cannot even try to click to mount it. 

 

What am I doing wrong? At first I thought it was because my remote share server started up later than the server that has UD installed on it but when I rebooted that server again thinking it would autoconnect after startup; it didn't. 

 

 

- Cheers,

Post diagnostics.

4 hours ago, dlandon said:

Post diagnostics.

Here you go. Link

So I keep a pre cleared sata drive connected in my system in case I need to replace a disk. Am I able to prevent it from spinning up by using the detach option and attaching it back when I need it? Thanks!

5 minutes ago, Johann said:

So I keep a pre cleared sata drive connected in my system in case I need to replace a disk. Am I able to prevent it from spinning up by using the detach option and attaching it back when I need it? Thanks!

Yes.  The good thing is it's powered off too.

5 hours ago, resentedpoet said:

Here you go. Link

Give me the output of this command:

/sbin/arp -a 'ROCKNETUNRAID'

 

11 hours ago, resentedpoet said:

Here you go. Link

I think I see the problem.  I'll issue an update to UD once I confirm the solution.

Since 6.12.4 (coming from 6.11.5) I do have trouble to copy files over SMB remotes. It doesn't make a difference if I copy from Unraid barebone to Unraid VM or between two Unraid VMs. I always see the following errors and the system stalls. I do have to kill the sessions to free the systems from this.

 

The error (example):

Tower unassigned.devices: Warning: shell_exec(/bin/df '/mnt/remotes/192.168.178.101_disk1' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 10s!

 

Remote SMB is registered like this:

/usr/local/sbin/rc.unassigned mount //192.168.178.101/disk1

 

On 6.11.5 this was never a problem.

 

Diagnostics attached.

 

Thanks in advance.

 

tower-diagnostics-20230910-1528.zip

10 hours ago, dlandon said:

I think I see the problem.  I'll issue an update to UD once I confirm the solution.

Thank you so much!

11 minutes ago, hawihoney said:

I do have to kill the sessions to free the systems from this.

 

It looks to me that you are pushing your system too much.  You have 22 individual disks mounted on two servers.  44 mounts total and many disks at 100% used:

//192.168.178.102/disk1   5.5T  5.5T   20G 100% /mnt/remotes/192.168.178.102_disk1
//192.168.178.102/disk2   5.5T  5.5T   10G 100% /mnt/remotes/192.168.178.102_disk2
//192.168.178.102/disk3   5.5T  5.5T   13G 100% /mnt/remotes/192.168.178.102_disk3
//192.168.178.102/disk4   5.5T  5.5T   20G 100% /mnt/remotes/192.168.178.102_disk4
//192.168.178.102/disk5   5.5T  5.5T   22G 100% /mnt/remotes/192.168.178.102_disk5
//192.168.178.102/disk6   5.5T  5.5T   13G 100% /mnt/remotes/192.168.178.102_disk6
//192.168.178.102/disk7   5.5T  5.5T   36G 100% /mnt/remotes/192.168.178.102_disk7
//192.168.178.102/disk8   5.5T  5.5T  9.1G 100% /mnt/remotes/192.168.178.102_disk8
//192.168.178.102/disk9   5.5T  5.5T   13G 100% /mnt/remotes/192.168.178.102_disk9
//192.168.178.102/disk10  5.5T  5.5T   12G 100% /mnt/remotes/192.168.178.102_disk10
//192.168.178.102/disk11  5.5T  5.5T  8.3G 100% /mnt/remotes/192.168.178.102_disk11
//192.168.178.102/disk12  5.5T  5.5T   13G 100% /mnt/remotes/192.168.178.102_disk12
//192.168.178.102/disk13  5.5T  5.5T   30G 100% /mnt/remotes/192.168.178.102_disk13
//192.168.178.102/disk14  5.5T  5.5T   33G 100% /mnt/remotes/192.168.178.102_disk14
//192.168.178.102/disk15  5.5T  5.5T   30G 100% /mnt/remotes/192.168.178.102_disk15
//192.168.178.102/disk16  5.5T  5.5T   13G 100% /mnt/remotes/192.168.178.102_disk16
//192.168.178.102/disk17  5.5T  5.5T   14G 100% /mnt/remotes/192.168.178.102_disk17
//192.168.178.102/disk18  5.5T  5.5T   30G 100% /mnt/remotes/192.168.178.102_disk18
//192.168.178.102/disk19  5.5T  5.5T   11G 100% /mnt/remotes/192.168.178.102_disk19
//192.168.178.102/disk20  5.5T  5.5T   20G 100% /mnt/remotes/192.168.178.102_disk20
//192.168.178.102/disk21  5.5T  5.5T   25G 100% /mnt/remotes/192.168.178.102_disk21
//192.168.178.102/disk22  5.5T  5.5T   17G 100% /mnt/remotes/192.168.178.102_disk22
//192.168.178.101/disk1    17T   17T  206G  99% /mnt/remotes/192.168.178.101_disk1
//192.168.178.101/disk2    17T   16T  458G  98% /mnt/remotes/192.168.178.101_disk2
//192.168.178.101/disk3   5.5T  5.4T  139G  98% /mnt/remotes/192.168.178.101_disk3
//192.168.178.101/disk4    17T   17T   73G 100% /mnt/remotes/192.168.178.101_disk4
//192.168.178.101/disk5    17T   17T   51G 100% /mnt/remotes/192.168.178.101_disk5
//192.168.178.101/disk6    17T   17T  183G  99% /mnt/remotes/192.168.178.101_disk6
//192.168.178.101/disk7    17T   17T  6.7G 100% /mnt/remotes/192.168.178.101_disk7
//192.168.178.101/disk8    17T   17T   17G 100% /mnt/remotes/192.168.178.101_disk8
//192.168.178.101/disk9   5.5T  5.4T   66G  99% /mnt/remotes/192.168.178.101_disk9
//192.168.178.101/disk10   17T   17T  119G 100% /mnt/remotes/192.168.178.101_disk10
//192.168.178.101/disk11   17T   17T   17G 100% /mnt/remotes/192.168.178.101_disk11
//192.168.178.101/disk12  5.5T  5.3T  208G  97% /mnt/remotes/192.168.178.101_disk12
//192.168.178.101/disk13   17T   17T   61G 100% /mnt/remotes/192.168.178.101_disk13
//192.168.178.101/disk14   17T   17T   39G 100% /mnt/remotes/192.168.178.101_disk14
//192.168.178.101/disk15  5.5T  5.5T   16G 100% /mnt/remotes/192.168.178.101_disk15
//192.168.178.101/disk16   17T   17T   15G 100% /mnt/remotes/192.168.178.101_disk16
//192.168.178.101/disk17  5.5T  5.5T   39G 100% /mnt/remotes/192.168.178.101_disk17
//192.168.178.101/disk18  5.5T  5.5T   48G 100% /mnt/remotes/192.168.178.101_disk18
//192.168.178.101/disk19   17T   15T  2.0T  89% /mnt/remotes/192.168.178.101_disk19
//192.168.178.101/disk20   17T  7.3T  9.1T  45% /mnt/remotes/192.168.178.101_disk20
//192.168.178.101/disk21  5.5T  5.4T   64G  99% /mnt/remotes/192.168.178.101_disk21
//192.168.178.101/disk22   17T   17T   69G 100% /mnt/remotes/192.168.178.101_disk22

UD has to do a 'df' on 44 mount points.  All this over a one 1GB NIC (you are only using eth0) using SMB?  Why don't you use root shares instead of mounting each and every disk separately?  That would be one 'df' per server.

 

The 'df' timeout could be extended in UD, but that would just stop the log messages about the command taking too long.

 

You might try the following:

• Use a Root Share instead of individual disk mounts.
• Switch to NFS remote shares.  It may be faster and avoid this issue.
• Cut down on the simultaneous disk mounts.  Only do a few at a time.  Why remote mount all disks?  You can't write to disks that are 100% used.
• Use both your NICs.  Bond your two NICs using one of the balancing modes - like 'balance-alb' that doesn't require switch configuration.

33 minutes ago, hawihoney said:

The error (example):

Tower unassigned.devices: Warning: shell_exec(/bin/df '/mnt/remotes/192.168.178.101_disk1' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 10s!

 

This is not the causing the stalling; it is an effect of the system stalling.

1 minute ago, resentedpoet said:

Thank you so much!

Try today's update and see if it is resolved.  Once you update, it may take several minutes for UD to show the online status.

I'm relatively new to Unraid, having started using it just yesterday, so it's possible I made a mistake somewhere. I was using Unassigned Devices to mount some old HDDs and transfer their data. Everything was working fine until I received a notification about a new update. After updating, I've encountered an issue – I can no longer mount the drive I was using just an hour ago.

Where the mount button is typically located, there's now a greyed-out "UDEV" with a crossed-out circle next to it. I'm unsure how to proceed in fixing this problem.

htpc-diagnostics-20230910-1649.zip

Edited September 10, 20232 yr by OmegaCrit
Diagnostics

1 minute ago, OmegaCrit said:

I'm relatively new to Unraid, having started using it just yesterday, so it's possible I made a mistake somewhere. I was using Unassigned Devices to mount some old HDDs and transfer their data. Everything was working fine until I received a notification about a new update. After updating, I've encountered an issue – I can no longer mount the drive I was using just an hour ago.

Where the mount button is typically located, there's now a greyed-out "UDEV" with a crossed-out circle next to it. I'm unsure how to proceed in fixing this problem.

Post diagnostics.

Added the diagnostics to my previous post but must have been to late for you to see it here is a new one I have one drive that i can mount and one that is giving me the udev error

htpc-diagnostics-20230910-1654.zip