Hello,
Some customers run our devices behind very restrictive firewalls that block access to NTP servers. This unfortunately means that the devices can’t do their normal time synchronization routine.
As a workaround, in one of my app containers I can get the current time from an http source. However, once I have the correct time, I cannot write that time to the system clock. I’ve tried the library (and the underlying commands) mentioned in this discussion, but the input is rejected as “Operation not permitted”:
bash-5.1# date
Sat Jun 19 07:43:46 UTC 2021
bash-5.1# date -s '01:00:00'
date: can't set date: Operation not permitted
Sat Jun 19 01:00:00 UTC 2021
bash-5.1# date
Sat Jun 19 07:43:54 UTC 2021
Is there any reason why the container would not have permission/ability to set the date? The only thing that sticks out so far is that the container is Alpine-based - I’ve already had to change the date format used due to Busybox limitations.
Probably because it isn’t reaching out from the container to the host. The discussion you mentioned talks about including the io.balena.features.dbus: '1' label, which allows communication to the host. Running a ‘date’ command in the container may only speak to the container and you want to communicate with the host OS.
NTP server blocking is odd though, as Balena use their own NTP server addresses which it is unlikely someone would have blocked. Unless the NTP port is blocked for all services perhaps? But again very odd. If you know of NTP servers that can be accessed, such as Google’s, you could set those as the default instead of Balena’s and may resolve the issue: Time management - Balena Documentation
You are correct; this is something else I should have been clearer on. The customer’s network blocks all traffic on port 123. Since the NTP port is blocked, I don’t know of any NTP services that will work.
Perhaps running the container with the privileged flag? May also want to read about the --cap-add SYS_TIME flag, or mounting /etc/localtime:/etc/localtime? I’m taking a stab in the dark a bit now.
Might be worth posting the relevant parts of your docker-compose and Dockerfiles here, it will make it easier for people to comment.
Aha, that fixes it! Using the privileged flag or cap_add: SYS_TIME works. I had attempted to try privileged previously, but I realized I updated the wrong docker_compose file.