2 minutes ago, broncosaddict said:

No dockers, docker's not even enabled.   No VM's, though it's enabled, have not created any.

 

Don't know if it matters, but I'm not using any of the onboard ethernet, I have a 10g NIC, with one direct connect to the other unraid server (same type 10g NiC card) and the other to network.

 

If the network was not up or was blocked, wouldn't that also block me from the unraid GUI?

It's probably a timing issue and is taking longer than 2 minutes to be ready.  If you can click on the 'Mount' button after some time and it mounts, then it is a timing issue.

11 minutes ago, dlandon said:

It's probably a timing issue and is taking longer than 2 minutes to be ready.  If you can click on the 'Mount' button after some time and it mounts, then it is a timing issue.

Yep. I absolutely can.  It does turn grey for a short time after the array is done starting, but then comes back to orange.  Click and connects no problem.   Is there anyway I can change the 2 minute delay to be longer?

 

Ok. I'm a dork, it's right there is the config settings.  I've upped it to 10 minutes...fingers crossed

Edited January 12, 20242 yr by broncosaddict

2 minutes ago, broncosaddict said:

Yep. I absolutely can.  It does turn grey for a short time after the array is done starting, but then comes back to orange.  Click and connects no problem.   Is there anyway I can change the 2 minute delay to be longer?

You can't change the time, but you can get around it.  Install the User Scripts plugin and set up a script to run on first array start.  Enter this script and adjust the time delay to your liking:

sleep 10	// wait for 10 seconds after the array is started

// auto mount UD remote shares
/usr/local/sbin/rc.unassigned mount autoshares

 

It won't cause any issues with UD when it is run at  later time.

So the "Remote share mount wait time:" in the common settings is for something different?

Just now, broncosaddict said:

So the "Remote share mount wait time:" in the common settings is for something different?

Thats for a wait after the network is up.

9 minutes ago, broncosaddict said:

So the "Remote share mount wait time:" in the common settings is for something different?

I'll increase the time UD waits for the network to become active to 5 minutes in the next release.  It doesn't slow anything down except for the time it takes for UD to mount remote shares.

5 minutes ago, dlandon said:

Thats for a wait after the network is up.

I thought that was the problem, the automount was starting before the network came up, wouldn't this delay the mount until after?

 

Is it possible, the network not up is a false positive?   I just rebooted it, logged in immediately, it was just starting to do the array.   I open an ssh window and was able to resolve and connect to the other unraid server both via ip and server name.  

The array was still coming up when I finished those tests.

Wouldn't that mean the network is actually up?

3 minutes ago, broncosaddict said:

I thought that was the problem, the automount was starting before the network came up, wouldn't this delay the mount until after?

 

Is it possible, the network not up is a false positive?   I just rebooted it, logged in immediately, it was just starting to do the array.   I open an ssh window and was able to resolve and connect to the other unraid server both via ip and server name.  

The array was still coming up when I finished those tests.

Wouldn't that mean the network is actually up?

Go to a command line and give me the output of this command:

route -n | awk '/^0.0.0.0/ {print $2; exit}'

 

1 minute ago, dlandon said:

Go to a command line and give me the output of this command:

route -n | awk '/^0.0.0.0/ {print $2; exit}'

 

It returned the firewall/gateway IP.  
root@rivers1:~# route -n | awk '/^0.0.0.0/ {print $2; exit}'
192.168.1.1
root@rivers1:~# 

 

Do you want me to reboot and do it before the array gets up?

Just now, broncosaddict said:

It returned the firewall/gateway IP.  
root@rivers1:~# route -n | awk '/^0.0.0.0/ {print $2; exit}'
192.168.1.1
root@rivers1:~# 

 

Do you want me to reboot and do it before the array gets up?

Yes, if you can catch it.

2 minutes ago, dlandon said:

Yes, if you can catch it.

yea, that's not a problem.  It takes a minute or two for the array to finish starting.  Give me a minute

Just now, broncosaddict said:

yea, that's not a problem.  It takes a minute or two for the array to finish starting.  Give me a minute

See if my idea of 5 minutes makes some sense.

5 minutes ago, broncosaddict said:

yea, that's not a problem.  It takes a minute or two for the array to finish starting.  Give me a minute

Same output and that was before it even mounted the first disk of the array.

I repeatedly ran it through the entire startup sequence thinking maybe it drops or hiccups, but it constantly returned the same 192.168.1.1

When the array finished the ud button went grey and after about 10 seconds or so it turned back orange saying "mount".  Was running the command repeatedly during the entire time and it never hesitated or paused giving me the same output.

9 minutes ago, dlandon said:

See if my idea of 5 minutes makes some sense.

I have no problem giving it a shot.  Let me get the script in place and bounce.

3 minutes ago, broncosaddict said:

I have no problem giving it a shot.  Let me get the script in place and bounce.

The final test is to see if the gateway address responds to a ping.  See if the ip address returned responds to a ping.

21 minutes ago, dlandon said:

The final test is to see if the gateway address responds to a ping.  See if the ip address returned responds to a ping.

So the automount is working with the script....yay!!

I'll bounce again to see about the ping and verify the automount still works.

31 minutes ago, dlandon said:

The final test is to see if the gateway address responds to a ping.  See if the ip address returned responds to a ping.

It never responds.  I checked my other server as well as pc and same thing.  Thinking about, I think set it somewhere to not respond to ping.

I don't know if it matters, but in this particular case the mount would not be hitting the network.  It is directly connected to the other unraid server and is pingable from the start.

Something odd as well, I set the script to sleep for 300 (5 minutes), however once the array was done (maybe even before, I'll bounce again to confirm) the mount was mounted.   Uptime of the server was 3 minutes....so it should have still been sleeping....right?

 

1 hour ago, dlandon said:

See if my idea of 5 minutes makes some sense.

So rebooted again and watched it.   As soon as it the array and cache drives were mounted and turned green, the share went grey for about 5-10 seconds and changed to orange "UN-MOUNT".    I timed it, I logged in immediately when the login page was displayed, the share was mounted in just under 2 minutes.  Very odd considering the only thing we did was add a script to sleep for 5 minutes before doing the automount.

I just looked at the script log and I see what happened.  I didn't really think about it, but just I cut and pasted your code in and only changed sleep 10 to sleep 300.

What I assume you meant as comments used the // instead of #, so it caused sleep to fail due to syntax and ran the automount right away...which is why it mounted immediately after the array started. 

I am perfectly fine with this as a solution, I don't think you need to change any time delays.

Let me know if you need/want any other testing.   

For the next week or so, I'll be working on setting everything up so it's not really "live" yet which means I can mess with it any way needed.  

 

Thanks for your help!!

On 1/12/2024 at 6:39 PM, broncosaddict said:

I just looked at the script log and I see what happened.  I didn't really think about it, but just I cut and pasted your code in and only changed sleep 10 to sleep 300.

What I assume you meant as comments used the // instead of #, so it caused sleep to fail due to syntax and ran the automount right away...which is why it mounted immediately after the array started. 

I am perfectly fine with this as a solution, I don't think you need to change any time delays.

Let me know if you need/want any other testing.   

For the next week or so, I'll be working on setting everything up so it's not really "live" yet which means I can mess with it any way needed.  

 

Thanks for your help!!

Sorry about the comment issue.  I have been working in php all day.  You don't need any time delay there.  The one in the UD Settings applies to the rc.unassigned call you are using.

 

The check for the network to be available is it has to find a gateway IP address and that IP address needs to respond to a ping.  I'm in the process of removing all pings for remote server status (converting to port scans) and I'll come up with a different approach for this network check.

20 hours ago, dlandon said:

Sorry about the comment issue.  I have been working in php all day.  You don't need any time delay there.  The one in the UD Settings applies to the rc.unassiugned call you are using.

 

The check for the network to be available is it has to find a gateway IP address and that IP address needs to respond to a ping.  I'm in the process of removing all pings for remote server status (converting to port scans) and I'll come up with a different approach for this network check.

Not a problem, happens to me all the time between bash and pl/sql.

 

The solution you provided with the script I think will actually work better for me as it mounts it immediately before the dockers start up.   A couple of dockers reference the link and I always feel better when the share is mounted before they start.  

(I saw somewhere the normal automount function doesn't start until after docker)

 

Thanks again for your help.  Much Appreciated! 

On 1/1/2024 at 1:05 PM, dlandon said:

UD starts when the array comes on-line.  Docker starts after UD mounts disks, but before remote shares are mounted.

 

When you manually start the array, UD will perform it's auto mount operations when it detects the array has started.

HI,

 

Here is my log files 

 

I rebooted Unraid and manually started the Array - and waited for UD to mount but it didn't do anything

 

Log is suggesting synology nas is offline ? but it has an uptime of 70 days.

 

thanks

 

tower-diagnostics-20240114-0914-UD.zip

2 hours ago, Unraidmule said:

 

I rebooted Unraid and manually started the Array - and waited for UD to mount but it didn't do anything

 

Log is suggesting synology nas is offline ? but it has an uptime of 70 days.

UD tried to mount the SYNOLOGY remote share but it detected it is offline:

Jan 14 09:12:55 Tower unassigned.devices: Mounting 'Auto Mount' Remote Shares...
Jan 14 09:12:55 Tower unassigned.devices: Using Gateway '10.0.0.1' to Ping Remote Shares.
Jan 14 09:12:55 Tower unassigned.devices: Waiting 5 secs before mounting Remote Shares...
Jan 14 09:12:56 Tower avahi-daemon[11644]: Server startup complete. Host name is Tower.local. Local service cookie is 2168445332.
Jan 14 09:12:57 Tower avahi-daemon[11644]: Service "Tower" (/services/ssh.service) successfully established.
Jan 14 09:12:57 Tower avahi-daemon[11644]: Service "Tower" (/services/smb.service) successfully established.
Jan 14 09:12:57 Tower avahi-daemon[11644]: Service "Tower" (/services/sftp-ssh.service) successfully established.
Jan 14 09:13:00 Tower unassigned.devices: Mounting Remote Share '//SYNOLOGY/home'...
Jan 14 09:13:00 Tower unassigned.devices: Remote Server 'SYNOLOGY' is offline and remote share 'home' cannot be mounted.

Some questions:

• Does the 'Mount' button show orange or gray?
• If it is orange, will it mount manually when you click the 'Mount' button?  If this works go to the UD Settings and increse the 5 second time delay before auto mounting remote shares.
• Does the SYNOLOGY respond to a ping?  UD uses a ping to determine if the remote server is online.  

I have an issue with my WD 14TB drive sleeping on a custom schedule.

 

I added hdparm -S12 $device to my HDD script in unassigned devices but the drive does not spin down after 60 seconds as per the hdparm -S12 paramater. I have also enabled disk sleep in UNRAID settings to its lowest setting of 15 minutes. 

 

How do I get the drive to sleep after 60 seconds and not 15 minutes? 

30 minutes ago, mikeyosm said:

How do I get the drive to sleep after 60 seconds and not 15 minutes? 

afaik not at all ... hdparm will put it into sleep (prolly) but webui is waking it up instantly then as its not triggered by the system spindown event ... thats how far i cam when i wanted to add a custom spindown to my disks

 

in the end i live with the 15 min