I suspect this could be a timing issue similar to the need of having to use the "waitusb=n" boot code in case of USB pendrives. To test this theory you could just insert a line with sleep 15 into '/opt/bootlocal.sh' before your 'mount' command. If that works just reduce the delay time from 15 seconds to a shorter value that still works for you.
I obviously have no idea what processes are running on your system at the time of the execution of '/opt/bootlocal.sh'. But as an alternative (or add-on) to the "trial & error" approach mentioned above you might get a better idea by (temporarily) using the 'syslog' boot code. This has the effect that 'dmesg' messages are stored with timestamps in '/var/log/messages'. You could then insert at the very beginning of '/opt/bootlocal.sh' an entirely harmless command like sudo id. This should leave an entry in '/var/log/messages' and you might be able to find out what other stuff is not yet finished by looking at the 'dmesg' messages following this "marker". Unfortunately there is no absolute guarantee that events in the syslog a captured in their exact sequence if those events are only some milliseconds apart from each other, but it still might be worth a shot.