How to restore /jffs/zoneinfo?

[XIII]

Today I discovered that the shell is reporting UTC time instead of my local timezone (CEST):

date
Wed Jun 18 13:09:40 UTC 2025

I tried to fix that by setting the TZ variable:

export TZ=Europe/Berlin
date
Wed Jun 18 13:09:40 Europe 2025

So while the text changes from "TZ" to "Europe" the hours remain the same (13) instead of the +2 for CEST (15).

Then I noticed that /etc/localtime is a link to a file in /jffs/zoneinfo, but the entire "zoneinfo" folder does not exist in JFFS on my GT-AX6000 (running ASUSWRT-Merlin 3006.102.4_0).

1. How can I fix this?
2. Can I use "CEST" instead of "Europe/Berlin"? (which I used as an example)

 

[XIII]

Manually linking /etc/localtime to /opt/share/zoneinfo/Europe/Berlin seems to fix this, but will this survive a reboot?

(Or do I need to do this in a script that is executed every boot?)

 

[ColinTaylor]

Then I noticed that /etc/localtime is a link to a file in /jffs/zoneinfo, but the entire "zoneinfo" folder does not exist in JFFS on my GT-AX6000 (running ASUSWRT-Merlin 3006.102.4_0).

I've never heard of a /jffs/zoneinfo directory existing before. So unless this is something new in the 3006.102 firmware I'm guessing that some third party script created it.

Normally /etc/localtime points to something under /rom/usr/share/zoneinfo as defined in the webUI. e.g.

# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Jun  4 11:22 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Dublin

See also this recent discussion regarding the difference between /etc/localtime and $TZ:

amtm - amtm 6.0.1 - the Asuswrt-Merlin Terminal Menu, May 31, 2025

It's the same check. To be frank, with MerlinAU doing a better job and the current state of the GT-BE Pro and non-Pro firmware release cycle I'm dropping the firmware update check function in amtm. I cannot test it properly with the only GT-BE router available in Switzerland and I am already...

www.snbforums.com

I suggest you disable JFFS custom scripts and configs in the webUI, reboot and see what /etc/localtime now points to.

 

[dave14305]

I think this extra zoneinfo comes from the NextDNS installation.

 

[ColinTaylor]

I think this extra zoneinfo comes from the NextDNS installation.

Really!? That would be pretty nasty behaviour.

 

[dave14305]

Really!? That would be pretty nasty behaviour.

nextdns/host/service/merlin/service.go at a575d7afc94f93dd92584e54158ac1af87d9cd14 · nextdns/nextdns

NextDNS CLI client (DoH Proxy). Contribute to nextdns/nextdns development by creating an account on GitHub.

github.com

 

[XIII]

I do indeed run the NextDNS CLI Client... Good catch!

(Surprised I haven't noticed this before)

Confirmed: after restarting the NextDNS client, /etc/localtime again points to /jffs/timezone...

 

[ColinTaylor]

nextdns/host/service/merlin/service.go at a575d7afc94f93dd92584e54158ac1af87d9cd14 · nextdns/nextdns

NextDNS CLI client (DoH Proxy). Contribute to nextdns/nextdns development by creating an account on GitHub.

github.com

Yuk. The problem nowadays is that when NextDNS tries to create /jffs/zoneinfo or download anything into it asd immediately deletes it.

 

[XIII]

Yes, I suffer from way more `asd` deletions than I'd like (all false positives).

Why are all the custom scripts generated by this community not affected by `asd`?

 

[dave14305]

Why are all the custom scripts generated by this community not

I believe Asus setup exclusions for the scripts and addons directories unique to Merlin.

More on asd...

About two years ago I was having problems with my Entware installation on an RT-AC86U. Files on the Entware distribution that started with "cr" (either case) were disappearing at 07:39 or 13:39. This stopped gcc working.... I eventually tracked it down to asd...

www.snbforums.com

 

[ColinTaylor]

Why are all the custom scripts generated by this community not affected by `asd`?

Probably because they don't put stuff in /jffs unless it's under /jffs/scripts, /jffs/configs or /jffs/addons. Anywhere else and it's likely to be deleted.