PBS 3.4 – "access time safety check failed" on NFS datastore (worked in 3.3)

luckyluc06

New Member
Jul 11, 2025
2
0
1
Hello everyone,


Since updating Proxmox Backup Server from version 3.3 to 3.4, I’m encountering a blocking error when creating or using a datastore mounted via NFS. Here’s the error output:

Code:
2025-06-30T09:23:50+02:00: Chunk metadata was not correctly updated during access time safety check:

2025-06-30T09:23:50+02:00: Timestamps before update: accessed Some(SystemTime { tv_sec: 1751268229, tv_nsec: 214397000 }), modified Some(SystemTime { tv_sec: 1751268229, tv_nsec: 214397000 }), created None

2025-06-30T09:23:50+02:00: Timestamps after update: accessed Some(SystemTime { tv_sec: 1751268229, tv_nsec: 214397000 }), modified Some(SystemTime { tv_sec: 1751268229, tv_nsec: 214397000 }), created None

2025-06-30T09:23:50+02:00: TASK ERROR: access time safety check failed: access time safety check using newly inserted chunk failed, aborting GC!

Context / What I’ve tried so far:

  • This works fine on PBS 3.3 with the exact same NFS datastore.
  • Fails consistently on PBS 3.4, even after a clean installation.
  • I tried multiple mount options: atime, strictatime, relatime, but none worked.
  • Permissions are fine, NFS is mounted with read/write access.

Main question:
Has anything changed regarding the access time safety check mechanism in PBS 3.4?
Is this a known bug or does PBS 3.4 now require more precise timestamp behavior (e.g., higher resolution or specific FS support)?


Thanks in advance for your help!
 
Hi,

Has anything changed regarding the access time safety check mechanism in PBS 3.4?
It has been introduced in 3.4 (from my memory).

Is this a known bug or does PBS 3.4 now require more precise timestamp behavior (e.g., higher resolution or specific FS support)?
It's not a bug, just your mounting point that has a "false" timestamp that can lead to "bad" GC and thus delete used chuck (which is bad) [very simplified version].

What exactly is your NFS mount ?

Best regards,
 
this means that your NFS server is lying - PBS explicitly ask it to update the timestamp of a file, the server says "OK, I've done that" but doesn't actually update the timestamp.. GC relies on this working, so please ensure that the export/server settings don't include something that discards timestamp updates..

what kind of system is providing the NFS share?
 
Hello everyone,

Thank you for your answers. So, yes, this is partly caused by the change from 3.3 to 3.4 because we retested in 3.3 and it worked. I can also confirm that for it to work in 3.4, you need to change this "time-stamping" parameter on the server on which the nfs is based.

Thanks again!

Lucien
 
So, yes, this is partly caused by the change from 3.3 to 3.4 because we retested in 3.3 and it worked.
Just to clarify, this change was introduced on purpose! The check is there to protect from creating datastores or running garbage collection on datastores which do not handle the atime updates as expected. Without that, you might have data loss.

I can also confirm that for it to work in 3.4, you need to change this "time-stamping" parameter on the server on which the nfs is based.
This is the correct solution! You must enable timestamp support on the server for PBS to work correctly, this is a requirement.
 
  • Like
Reactions: Johannes S