I have a local mirror (created with debmirror), and when I run apt-get update after a few days, I get this:

E: Release file expired, ignoring file:/home/wena/.repo_bin/dists/sid/Release (invalid since 14h 31min 45s)

How do I work around that?

  • 4
    Security Warning: This question asks for a work around. However it is better to fix the mirror or point to a working one. I changed to point at httpredir.debian.org/debian and it started working again. Commented Jun 2, 2017 at 7:37
  • Switch to a different mirror and it'll work. Commented Jul 21, 2018 at 12:49
  • 4
    What is "better" depends on what your goals are. If your goal is to get the latest packages from Debian then changing mirror is the right soloution. If your goal is to use the older mirror that you have locally so you can get on with your work where Internet is unavailable or expensive then turning off the expiry check is the right solution. If your goal is to update to a specific older version of the repo for bug triage reasons then again turning off the expiry check is the right solution.
    – plugwash
    Commented Sep 20, 2018 at 19:11
  • 1
    Indeed, I reached this message while using Debian Archive for a Debian Wheezy system that can't be updated.
    – JucaPirama
    Commented May 23, 2019 at 16:21

10 Answers 10


Add this to the command:

-o Acquire::Check-Valid-Until=false

For example:

sudo apt-get -o Acquire::Check-Valid-Until=false update
  • 16
    This worked, but some explanation of why it did would be useful. Commented Sep 9, 2014 at 23:17
  • 4
    This deactivates the check which verifies expired digital signatures, so apt will accept old and expired release keys as well.
    – grin
    Commented May 31, 2017 at 11:05
  • 9
    Security Warning: This answer is a work around (as asked for). However it is better to fix the mirror or point to a working one. I changed to point at httpredir.debian.org/debian and it started working again. Commented Jun 2, 2017 at 7:36
  • 4
    you cannot switch that easily for already deprecated releases like say debian 6 where you need to use archives.debian.org to get any packages now Commented Aug 23, 2018 at 13:46
  • Does not work with Raspbian 10. Commented Nov 7, 2019 at 16:53

If you do not care about this check, no matter for which mirror, just create a file in /etc/apt/apt.conf.d/ (e.g. name it 10no--check-valid-until) and put the option directly in there:

Acquire::Check-Valid-Until "0";

After this, you will never be bothered again with the mentioned warning at all.

  • 1
    Although the workaround itself isn't the optimal solution, I have a development box that I don't care about, so this annoyance simply gets in my way. I was able to use this answer with Ansible since I can't find any way to add the accepted answer to the action module when using ansible_pkg_mgr.
    – jia103
    Commented Nov 11, 2016 at 23:44
  • 4
    one command: echo "Acquire::Check-Valid-Until false;" | tee -a /etc/apt/apt.conf.d/10-nocheckvalid
    – rubo77
    Commented May 9, 2019 at 18:17
  • 2
    This is so good for legacy Dockerfiles. Stick this as the first line in a Dockerfile and all your problems go away. Thanks Commented Jun 1, 2020 at 22:23

The release files have a valid-until entry, e.g. Valid-Until: Thu, 07 Oct 2010 08:17:56 UTC

If the release file isn't valid anymore, you should run debmirror again to check if there are any changes in the repository. One change will be the release file and you will get a new validity for it.

You could easily automate this with a crontab entry.

  • Thanks for that one. I should have looked inside that file before asking. Curiously though, is this a new thing? It didn't happen before (but once).
    – tshepang
    Commented Sep 30, 2010 at 11:58
  • I don't use debian really often at the moment, but maybe they just changed the release file cycles to a shorter date...
    – echox
    Commented Sep 30, 2010 at 12:03

This can also happen if your system date/time is wrong. I fixed it by correcting my local time before doing the update.

  • So helpful. Ran into this on Windows 10 + WSL2... Wasn't clear from the error it was system clock dependent, but correcting local time was exactly what was needed.
    – kevlarr
    Commented Apr 15, 2021 at 15:13
  • SSL / TLS depends on (in principle) the correct time setting... Commented Oct 3, 2021 at 12:57

Not sure whether its related with Jessie current issue (https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html) or not. but for those got a same error even already used

sudo apt-get -o Acquire::Check-Valid-Until=false update

and still occurred a same issue, can try this instead

echo 'Acquire::Check-Valid-Until no;' > /etc/apt/apt.conf.d/99no-check-valid-until

It works for me :)

  • Does not work with Raspbian 10.... Commented Nov 7, 2019 at 16:53

I removed /var/lib/apt/* and rerun apt-get update, and it works!

  • I do that for a completely different error, and it works for that one. This error is completely irrelevant.
    – snetch
    Commented Jul 10, 2017 at 17:21
  • Stupid error.... it still does not work with Raspbian 10 Commented Nov 7, 2019 at 16:54

Some of the mirrors out there might have stale files. This happened to me recently, and it was in also tied to the caching server I'm using (apt-cacher-ng) which tries to save bandwidth by redirecting the repositories for same archive to a single entity (in my case if was a Hungarian mirror). Direct updates through German mirror worked ok, for example. Try changing the mirror you're using. In case you're using apt-cacher-ng, you'll need to do something in the line of changing the following file's contents:

  • /etc/apt-cacher-ng/backends_debian
  • /etc/apt-cacher-ng/backends_debvol

After that you should also restart apt-cacher-ng for changes to take effect.

  • Note that I was asking for a workaround, not why this was happening (good answer though). In this case I was, knowingly, having a stale repository.
    – tshepang
    Commented May 13, 2011 at 12:44

I had this issue on Windows WSL2 Ubuntu trying to spin up a docker container. I ran the command below on the CLI and it corrected the time mismatch.

sudo hwclock -s

The mirror might not be expired.

Rather something else on your system might be messed up. Try this:

1) Temporarily comment out related lines from from /etc/apt/sources.list, or /etc/apt/source.list.d/*. For example after I commented out the following two lines, my error went away, (with the consequence that these archives were temporarily not used for reloads):

deb http://security.debian.org/ stretch/updates non-free contrib main
deb http://mirrors.ocf.berkeley.edu/debian/ stretch-updates main contrib non-free

2) Open synaptic and reload, or probably sudo apt-get update would also work.

3) Comment these lines back in.

4) Repeat step 2.

Fixed this for me. I'm guessing my apt cache got a bad date in it.

My problem occurred after restoring my / (root) and /var filesystems from btrfs snapshots to help fix a package install problem that occurred. The exact error message that I was getting was:

Release file for http://mirrors.ocf.berkeley.edu/debian/dists/stretch-updates/InRelease is expired (invalid since 5d 4h 50min 18s). Updates for this repository will not be applied. Release file for http://security.debian.org/dists/stretch/updates/InRelease is expired (invalid since 2d 2h 52min 43s). Updates for this repository will not be applied.


please check BIOS/System time, you should have the same time

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .