@reboot is not working in CRON

Take a look at the systemd.service manpage. It describes how to configure systemd to manage a service. I am sure you will find examples for your system in /usr/lib/systemd/system or similar paths.

In your case, the service would look somewhat like this:

[Unit]
Description=Unturned Game Server

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/bin/bash /home/steam/start.sh
Type=simple
User=steam
Group=steam
WorkingDirectory=/home/steam
Restart=on-failure

Put this in a file /etc/systemd/system/unturned.service. Then run systemctl daemon-reload (once, and whenever you change unturned.service to tell systemd to re-read the configuration) and systemctl start unturned.service to start the game server.

If that works as expected, you can use systemctl enable unturned.service to make sure it starts at boot.

A few notes on the options used:

• If start.sh is not supposed to run as user/group steam, edit appropriately.
• WantedBy in the Install section tells systemd which "target" (see man systemd.target) pulls the service in when you enable it using systemctl enable.
• Restart defines under which circumstances systemd will automatically restart the service. There are more restart-related options, which you may or may not want to change; see the systemd.service man page.

Try man 5 crontab. If your crontab supported, you should see @reboot, @yearly, @monthly,.,,,

then try add some sleep for moment may can help.

@reboot sleep 60;/root/s3-mount.sh

Check the critical-chain for crond.service, as asked and answered in This StackExchange post

Also, reference this FreeDesktop article addressing this issue.

In general, systemd is configured to have very limited dependencies, starting many daemons in parallel to reduce time spent booting. Services that are not necessarily dependent on the network being fully up and functional will fail if there are components that assume the network is in a stable state. Failures such as this may be difficult to diagnose, but using systemd-analyze critical-chain and journalctl -xel output can lead you to the root cause of your issue.