dlandon

The automount cannot be delayed. People use UD devices for Dockers and VMs and they need the UD device to be ready. I'm not an expert on the startup sequence of unRAID and the network, so I can't help there.

The permissions are not set right. There is a firstrun script that checks and then changes the permissions if they are not right. I need to see the Zoneminder log so I can see why the permissions are not being set. Just showing me the folder permissions doesn't help me solve your problem. We need to see why the permissions are not being reset. Post the Zoneminder log so I can see the Zoneminder startup. You should see the following: *** Running /etc/my_init.d/30_gen_ssl_keys.sh... using existing keys in "/config/keys" *** Running /etc/my_init.d/40_firstrun.sh... File zm.conf already exists You should see the 40_firstrun.sh entry and there should be a log entry where the permissions are changed.

The Zoneminder Docker is supposed to correct the permissions when it starts. Restart the docker and see if there isn't a message about correcting permissions.

The problem is that UD is trying to mount the NFS mounts before the network is up: Mar 29 11:13:14 BrownsBeast unassigned.devices: Error: Remote SMB/NFS server '192.168.2.230' is offline and share '192.168.2.230://volume1/video' cannot be mounted. Mar 29 11:13:14 BrownsBeast unassigned.devices: Error: Remote SMB/NFS server '192.168.2.230' is offline and share '192.168.2.230://volume1/photos' cannot be mounted. Mar 29 11:13:14 BrownsBeast emhttpd: Starting services... Mar 29 11:13:14 BrownsBeast emhttpd: shcmd (63): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 20 Mar 29 11:13:14 BrownsBeast kernel: BTRFS: device fsid e0a6a3d9-86b3-4967-8458-dc65511ef8d9 devid 1 transid 5602 /dev/loop2 Mar 29 11:13:14 BrownsBeast kernel: BTRFS info (device loop2): disk space caching is enabled Mar 29 11:13:14 BrownsBeast kernel: BTRFS info (device loop2): has skinny extents Mar 29 11:13:14 BrownsBeast root: Resize '/var/lib/docker' of 'max' Mar 29 11:13:14 BrownsBeast kernel: BTRFS info (device loop2): new size for /dev/loop2 is 21474836480 Mar 29 11:13:14 BrownsBeast emhttpd: shcmd (65): /etc/rc.d/rc.docker start Mar 29 11:13:14 BrownsBeast ntpd[1895]: Deleting interface #1 br0, 192.168.2.235#123, interface stats: received=11, sent=19, dropped=0, active_time=17 secs Mar 29 11:13:14 BrownsBeast ntpd[1895]: 193.104.228.123 local addr 192.168.2.235 -> <null> Mar 29 11:13:14 BrownsBeast ntpd[1895]: 212.99.225.86 local addr 192.168.2.235 -> <null> Mar 29 11:13:14 BrownsBeast ntpd[1895]: 62.242.89.196 local addr 192.168.2.235 -> <null> Mar 29 11:13:14 BrownsBeast ntpd[1895]: 92.246.24.225 local addr 192.168.2.235 -> <null> Mar 29 11:13:14 BrownsBeast root: starting dockerd ... Mar 29 11:13:14 BrownsBeast kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Your network appears to be starting late in the boot up process.

Good catch. I didn't even notice that.

I think we are all trying to keep users from causing themselves problems, but sometimes they just have to work it out on their own. Your efforts are commendable.

Posting diagnostics will be the only way I can help you.

Steps to reproduce: - Fresh boot into 6.5.0. - Switch OS from stable to next. - Switch OS from next back to stable. - Run '/usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck' Notice of update appears: Keep in mind the OS selection is on stable and notification shows next installed and next available for update.

I agree with @Squid

Which version of unRAID do you want me to start with? Any preference?

@bonienl I can reproduce the notice with @Squid's procedure.

I understand. How can I help you find it?

Changed Status to Open

I'll re-open this because it seems we haven't found the solution yet.

Probably the best way to handle it. Don't you know it's always your fault, and if it's not, it ought to be.

Running the update assistant on a 6.5.0 version and checking against 'next' changes the /tmp/plugins/unRAIDServer.plg to 'next'. This seems to be confusing @bonienl's code. I guess you two will have to sort out the best solution.

Not an unRaid issue.

Changed Status to Solved

That would explain it, because that's exactly what I did on all servers.

I normally don't select the "Next" selection on the 6.5.0 server. I may have done that at one time though just as a test. The problem is that I haven't made any changes in that server since 6 days ago when it was last booted and it just now showed a new version of unRAID. Did you notice that the notification shows the installed version as 6.5.1-rc2 and the new version as 6.5.1-rc2? How can this situation call for an update? How can the installed version show as 6.5.1-rc2 when 6.5.0 is installed? Is this because the /tmp/plugins/unRAIDServer.plg is 6.5.1-rc2?

Got 6.5.0 stable. My servers are in Ohio and the 6.50 server is in Texas. Yesterday I had a strange thing with Internet access. It went away for a while and wasn't due to anything on my end. Could there be a network situation with error recovery that would present the wrong version? EDIT: There is an unRAIDServer-.plg that shows as next.

Can't believe this hasn't come up before. I've not seen it.

Yes.

Next.