starred/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-02-05 00:29:55 +03:00
Code Issues 13 Packages Projects Releases 10 Wiki Activity

KeyCloak: can't cope with TZ 'Etc/UTC' #2166

New Issue
Closed
opened 2026-02-05 04:04:46 +03:00 by OVERLORD · 9 comments
OVERLORD commented 2026-02-05 04:04:46 +03:00
Owner
Copy Link

Originally created by @ralfbergs on GitHub (Dec 15, 2025).

✅ Have you read and understood the above guidelines?

yes

🔎 Did you run the script with verbose mode enabled?

Yes, verbose mode was enabled and the output is included below

📜 What is the name of the script you are using?

Keycloak

📂 What was the exact command used to execute the script?

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/keycloak.sh)"

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 13

📈 Which Proxmox version are you on?

9.1.1

📝 Provide a clear and concise description of the issue.

I tried to use "Advanced Settings" as below to install a Keycloak container:

var_unprivileged=1
var_cpu=2
var_ram=2048
var_disk=4
var_brg=vmbr0
var_net=dhcp
var_ipv6_method=auto
var_ssh=yes
var_apt_cacher=no
var_fuse=no
var_tun=no
var_gpu=no
var_nesting=1
var_keyctl=0
var_mknod=0
var_protection=yes
var_timezone=Etc/UTC
var_tags=
var_verbose=yes
var_hostname=kc2
var_template_storage=nas1-nfs
var_container_storage=samsung

The install scripts barfs about my TZ. My PVE instance is using Etc/UTC. I get the below error message:

+ pct create 113 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst -features nesting=1,keyctl=1 -hostname kc2 -tags 'community-script;access-management' -net0 name=eth0,bridge=vmbr0,ip=dhcp,ip6=auto -onboot 1 -cores 2 -memory 2048 -unprivileged 1 -protection 1 -timezone Etc/UTC -password verySecret -rootfs samsung:4
+ tee -a /tmp/pct_create_113_20251215_110644_c0834f02.log
400 Parameter verification failed.
timezone: invalid format - invalid time zone 'Etc/UTC'

pct create <vmid> <ostemplate> [OPTIONS]
+ set +x

When I use the default settings, creating the container does succeed, though.

🔄 Steps to reproduce the issue.

  1. Set your PVE instance to use UTC TZ.
  2. Execute the install script (this specific build).
  3. Select "Advanced Settings"
  4. Select container details as specified above
  5. Observe that the install script barfs with the above error message.

❌ Paste the full error output (if available).

  🧩  Using Advanced Install on node pve
  💡  PVE Version 9.1.1 (Kernel: 6.17.2-1-pve)

  💡  PVE Version 9.1.1 (Kernel: 6.17.2-1-pve)
  🖥️  Operating System: debian
  🌟  Version: 13
  📦  Container Type: Unprivileged
  🆔  Container ID: 113
  🏠  Hostname: kc2
  💾  Disk Size: 4 GB
  🧠  CPU Cores: 2
  🛠️  RAM Size: 2048 MiB
  🌉  Bridge: vmbr0
  📡  IPv4: dhcp
  📡  IPv6: auto
  🗂️  FUSE Support: no
  📦  Nesting: Enabled
  🎮  GPU Passthrough: no
  📦  Protection: Enabled
  💡  Timezone: Etc/UTC
  🔍  Verbose Mode: yes
  🚀  Creating a Keycloak LXC using the above advanced settings
  ✔️   Updated app defaults: /usr/local/community-scripts/defaults/keycloak.vars
  ✔️   Storage nas1-nfs (Free: 4.5TB  Used: 10.9TB) [Template]
  ✔️   Storage samsung (Free: 402.6GB  Used: 52.1GB) [Container]
  ✔️   Storage 'samsung' (dir) validated
  ✔️   Template storage 'nas1-nfs' validated
  ✔️   Template search completed
  ✔️   Template debian-13-standard_13.1-2_amd64.tar.zst [online]
  ✖️   Container creation failed. See /tmp/pct_create_113_20251215_110644_c0834f02.log
+ pct create 113 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst -features nesting=1,keyctl=1 -hostname kc2 -tags 'community-script;access-management' -net0 name=eth0,bridge=vmbr0,ip=dhcp,ip6=auto -onboot 1 -cores 2 -memory 2048 -unprivileged 1 -protection 1 -timezone Etc/UTC -password verySecret -rootfs samsung:4
+ tee -a /tmp/pct_create_113_20251215_110644_c0834f02.log
400 Parameter verification failed.
timezone: invalid format - invalid time zone 'Etc/UTC'

pct create <vmid> <ostemplate> [OPTIONS]
+ set +x

🖼️ Additional context (optional).

The dialog where it shows the TZ it copied from the PVE host:

Image

The error message after failing to set up the container:

Image
Originally created by @ralfbergs on GitHub (Dec 15, 2025). ### ✅ Have you read and understood the above guidelines? yes ### 🔎 Did you run the script with verbose mode enabled? Yes, verbose mode was enabled and the output is included below ### 📜 What is the name of the script you are using? Keycloak ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/keycloak.sh)" ### ⚙️ What settings are you using? - [ ] Default Settings - [x] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 13 ### 📈 Which Proxmox version are you on? 9.1.1 ### 📝 Provide a clear and concise description of the issue. I tried to use "Advanced Settings" as below to install a Keycloak container: ``` var_unprivileged=1 var_cpu=2 var_ram=2048 var_disk=4 var_brg=vmbr0 var_net=dhcp var_ipv6_method=auto var_ssh=yes var_apt_cacher=no var_fuse=no var_tun=no var_gpu=no var_nesting=1 var_keyctl=0 var_mknod=0 var_protection=yes var_timezone=Etc/UTC var_tags= var_verbose=yes var_hostname=kc2 var_template_storage=nas1-nfs var_container_storage=samsung ``` The install scripts barfs about my TZ. My PVE instance is using `Etc/UTC`. I get the below error message: ``` + pct create 113 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst -features nesting=1,keyctl=1 -hostname kc2 -tags 'community-script;access-management' -net0 name=eth0,bridge=vmbr0,ip=dhcp,ip6=auto -onboot 1 -cores 2 -memory 2048 -unprivileged 1 -protection 1 -timezone Etc/UTC -password verySecret -rootfs samsung:4 + tee -a /tmp/pct_create_113_20251215_110644_c0834f02.log 400 Parameter verification failed. timezone: invalid format - invalid time zone 'Etc/UTC' pct create <vmid> <ostemplate> [OPTIONS] + set +x ``` When I use the default settings, creating the container **does** succeed, though. ### 🔄 Steps to reproduce the issue. 1. Set your PVE instance to use UTC TZ. 2. Execute the install script ([this specific build](https://github.com/community-scripts/ProxmoxVE/blob/5f5144c6610ad2bd3ea52a2fb3889e0283f781fc/ct/keycloak.sh)). 3. Select "Advanced Settings" 4. Select container details as specified above 5. Observe that the install script barfs with the above error message. ### ❌ Paste the full error output (if available). ``` 🧩 Using Advanced Install on node pve 💡 PVE Version 9.1.1 (Kernel: 6.17.2-1-pve) 💡 PVE Version 9.1.1 (Kernel: 6.17.2-1-pve) 🖥️ Operating System: debian 🌟 Version: 13 📦 Container Type: Unprivileged 🆔 Container ID: 113 🏠 Hostname: kc2 💾 Disk Size: 4 GB 🧠 CPU Cores: 2 🛠️ RAM Size: 2048 MiB 🌉 Bridge: vmbr0 📡 IPv4: dhcp 📡 IPv6: auto 🗂️ FUSE Support: no 📦 Nesting: Enabled 🎮 GPU Passthrough: no 📦 Protection: Enabled 💡 Timezone: Etc/UTC 🔍 Verbose Mode: yes 🚀 Creating a Keycloak LXC using the above advanced settings ✔️ Updated app defaults: /usr/local/community-scripts/defaults/keycloak.vars ✔️ Storage nas1-nfs (Free: 4.5TB Used: 10.9TB) [Template] ✔️ Storage samsung (Free: 402.6GB Used: 52.1GB) [Container] ✔️ Storage 'samsung' (dir) validated ✔️ Template storage 'nas1-nfs' validated ✔️ Template search completed ✔️ Template debian-13-standard_13.1-2_amd64.tar.zst [online] ✖️ Container creation failed. See /tmp/pct_create_113_20251215_110644_c0834f02.log + pct create 113 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst -features nesting=1,keyctl=1 -hostname kc2 -tags 'community-script;access-management' -net0 name=eth0,bridge=vmbr0,ip=dhcp,ip6=auto -onboot 1 -cores 2 -memory 2048 -unprivileged 1 -protection 1 -timezone Etc/UTC -password verySecret -rootfs samsung:4 + tee -a /tmp/pct_create_113_20251215_110644_c0834f02.log 400 Parameter verification failed. timezone: invalid format - invalid time zone 'Etc/UTC' pct create <vmid> <ostemplate> [OPTIONS] + set +x ``` ### 🖼️ Additional context (optional). The dialog where it shows the TZ it copied from the PVE host: <img width="566" height="273" alt="Image" src="https://github.com/user-attachments/assets/b72765e9-d997-42c6-bb26-f386d612dd45" /> The error message after failing to set up the container: <img width="640" height="211" alt="Image" src="https://github.com/user-attachments/assets/6ff21aac-bbaf-4231-9b54-8b44c5a3ca1e" />
OVERLORD added the not a script issue label 2026-02-05 04:04:46 +03:00
OVERLORD commented 2026-02-05 04:05:02 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Dec 15, 2025):

that has nothing todo with keycloak, the error come directly from your proxmox. Proxmox cant create an LXC with this values, because ETC/UTC is not allowed. The error comes from the Proxmox validation of pct: --timezone does not accept arbitrary tzdata paths, but only values from /usr/share/zoneinfo/zone.tab (or “host”). Etc/UTC is not listed in zone.tab in many setups (because zone.tab usually contains “country-based” zones), hence: invalid format.

you can try without any timezone, "host" or an correct one

@MickLesk commented on GitHub (Dec 15, 2025): that has nothing todo with keycloak, the error come directly from your proxmox. Proxmox cant create an LXC with this values, because ETC/UTC is not allowed. The error comes from the Proxmox validation of pct: --timezone does not accept arbitrary tzdata paths, but only values from /usr/share/zoneinfo/zone.tab (or “host”). Etc/UTC is not listed in zone.tab in many setups (because zone.tab usually contains “country-based” zones), hence: invalid format. you can try without any timezone, "host" or an correct one
OVERLORD commented 2026-02-05 04:05:08 +03:00
Author
Owner
Copy Link

@ralfbergs commented on GitHub (Dec 15, 2025):

Thank you for your quick response.

that has nothing todo with keycloak, the error come directly from your proxmox. Proxmox cant create an LXC with this values, because ETC/UTC is not allowed. The error comes from the Proxmox validation of pct: --timezone does not accept arbitrary tzdata paths, but only values from /usr/share/zoneinfo/zone.tab (or “host”). Etc/UTC is not listed in zone.tab in many setups (because zone.tab usually contains “country-based” zones), hence: invalid format.

I don't fully understand this answer.

I selected a TZ of UTC (exactly the one I specified above, Etc/UTC), when I set up Proxmox. It was accepted, it is a proper TZ name, and it is obviously working well in Proxmox. I assume that many people use UTC as their TZ -- at least those who are familiar with proper hosting best practices.

So, when I set up a container, can I not expect that the logic for creating the container can cope with such a setting?

you can try without any timezone, "host" or an correct one

I would have selected host had I known that this is an option. Instead, Etc/UTC was given as the default, which made perfect sense to me, so I confirmed it.

Would it not be the correct approach to replace Etc/UTC by host in cases like this?

Or am I somehow not fully understanding this scenario?

Thank you.

@ralfbergs commented on GitHub (Dec 15, 2025): Thank you for your quick response. > that has nothing todo with keycloak, the error come directly from your proxmox. Proxmox cant create an LXC with this values, because ETC/UTC is not allowed. The error comes from the Proxmox validation of pct: --timezone does not accept arbitrary tzdata paths, but only values from /usr/share/zoneinfo/zone.tab (or “host”). Etc/UTC is not listed in zone.tab in many setups (because zone.tab usually contains “country-based” zones), hence: invalid format. I don't fully understand this answer. I selected a TZ of UTC (exactly the one I specified above, `Etc/UTC`), when I set up Proxmox. It was accepted, it is a proper TZ name, and it is obviously working well in Proxmox. I assume that many people use UTC as their TZ -- at least those who are familiar with proper hosting best practices. So, when I set up a container, can I not expect that the logic for creating the container can cope with such a setting? > you can try without any timezone, "host" or an correct one I would have selected `host` had I known that this is an option. Instead, `Etc/UTC` was given as the default, which made perfect sense to me, so I confirmed it. Would it not be the correct approach to replace `Etc/UTC` by `host` in cases like this? Or am I somehow not fully understanding this scenario? Thank you.
OVERLORD commented 2026-02-05 04:05:12 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Dec 15, 2025):

Proxmox itself may use Etc/UTC as the host time zone → completely correct, but;

  • pct create --timezone does not accept the same values as the Proxmox host.
  • For containers, Proxmox only allows a limited list of time zones (from zone.tab) or the special value host.
  • Etc/UTC is a valid Linux TZ, but not a valid pct container TZ → hence the error.

This is not a bug in the script, nor is it a Keycloak issue, but rather a design limitation of Proxmox.

I selected a TZ of UTC (exactly the one I specified above, Etc/UTC), when I set up Proxmox. It was accepted, it is a proper TZ name, and it is obviously working well in Proxmox. I assume that many people use UTC as their TZ -- at least those who are familiar with proper hosting best practices.

1.) The host uses tzdata directly.
2.) LXC containers are created via pct with strict validation.
3.) pct does not allow all tzdata names, only:

  • host
  • or zones such as Europe/Berlin, America/New_York, etc.

This is somewhat inconsistent, but that is how it is implemented. (Proxmox)

Would it not be the correct approach to replace Etc/UTC by host in cases like this?

Yes, that's a valid point. A clean solution would be, for example:

  • If var_timezone=Etc/UTC → map internally to host

But I'm not entirely sure whether it makes sense to set it that way, as it would actually somewhat bypass the protective mechanism on the part of Proxmox.

@MickLesk commented on GitHub (Dec 15, 2025): Proxmox itself may use Etc/UTC as the host time zone → completely correct, but; - pct create --timezone does not accept the same values as the Proxmox host. - For containers, Proxmox only allows a limited list of time zones (from zone.tab) or the special value host. - Etc/UTC is a valid Linux TZ, but not a valid pct container TZ → hence the error. This is not a bug in the script, nor is it a Keycloak issue, but rather a design limitation of Proxmox. > I selected a TZ of UTC (exactly the one I specified above, `Etc/UTC`), when I set up Proxmox. It was accepted, it is a proper TZ name, and it is obviously working well in Proxmox. I assume that many people use UTC as their TZ -- at least those who are familiar with proper hosting best practices. 1.) The host uses tzdata directly. 2.) LXC containers are created via pct with strict validation. 3.) pct does not allow all tzdata names, only: - host - or zones such as Europe/Berlin, America/New_York, etc. This is somewhat inconsistent, but that is how it is implemented. (Proxmox) > Would it not be the correct approach to replace `Etc/UTC` by `host` in cases like this? Yes, that's a valid point. A clean solution would be, for example: - If var_timezone=Etc/UTC → map internally to host But I'm not entirely sure whether it makes sense to set it that way, as it would actually somewhat bypass the protective mechanism on the part of Proxmox.
OVERLORD commented 2026-02-05 04:05:22 +03:00
Author
Owner
Copy Link

@ralfbergs commented on GitHub (Dec 15, 2025):

Thanks very much for taking the time to elaborate.

Everything is crystal-clear apart from the below:

Would it not be the correct approach to replace Etc/UTC by host in cases like this?

Yes, that's a valid point. A clean solution would be, for example:

* If var_timezone=Etc/UTC → map internally to host

But I'm not entirely sure whether it makes sense to set it that way, as it would actually somewhat bypass the protective mechanism on the part of Proxmox.

What do you mean by "protective mechanism on the part of Proxmox?" What does it protect against, and in how far would such a change sabotage the "protective mechanism?"

I cannot see how a change as suggested by myself above could be "damaging?"

By implementing this mapping, you basically give the user exactly what they want. By not implementing it, you have the user run into an issue -- being unable to create the container, with the root cause unclear.

To me it seems easy to decide what to do now... 😉

@ralfbergs commented on GitHub (Dec 15, 2025): Thanks very much for taking the time to elaborate. Everything is crystal-clear apart from the below: > > Would it not be the correct approach to replace `Etc/UTC` by `host` in cases like this? > > Yes, that's a valid point. A clean solution would be, for example: > > * If var_timezone=Etc/UTC → map internally to host > > But I'm not entirely sure whether it makes sense to set it that way, as it would actually somewhat bypass the protective mechanism on the part of Proxmox. What do you mean by "protective mechanism on the part of Proxmox?" What does it protect against, and in how far would such a change sabotage the "protective mechanism?" I cannot see how a change as suggested by myself above could be "damaging?" By implementing this mapping, you basically give the user exactly what they want. By **not** implementing it, you have the user run into an issue -- being unable to create the container, with the root cause unclear. To me it seems easy to decide what to do now... 😉
OVERLORD commented 2026-02-05 04:05:28 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Dec 15, 2025):

Fair question.

By “protective mechanism” I did not mean security, but rather a validation guard in pct. Proxmox intentionally restricts --timezone to values from zone.tab plus the special value host, to ensure container creation only uses timezones it can reliably validate and apply.

That said, mapping Etc/UTC → host would not meaningfully weaken this mechanism:

  • host is already an explicitly supported and trusted value
  • the resulting behavior (UTC inside the container) is exactly what the user intends

So this would not bypass validation, but simply translate a common and reasonable input into a form that pct accepts.

The remaining question is more about philosophy than correctness:

  • current behavior is strict pass-through and fails early
  • mapping would be more user-friendly and avoid a confusing hard error

Technically, both approaches are valid. I agree that mapping Etc/UTC to host would be a reasonable UX improvement, as long as it’s documented and transparent. But i can say, in the fact, its not an "issue" by us or Proxmox, its an work by Design - why? Nobody knows expect the Dev 😄

@MickLesk commented on GitHub (Dec 15, 2025): Fair question. By “protective mechanism” I did not mean security, but rather a validation guard in `pct`. Proxmox intentionally restricts `--timezone` to values from `zone.tab` plus the special value `host`, to ensure container creation only uses timezones it can reliably validate and apply. That said, mapping `Etc/UTC → host` would not meaningfully weaken this mechanism: - `host` is already an explicitly supported and trusted value - the resulting behavior (UTC inside the container) is exactly what the user intends So this would not bypass validation, but simply translate a common and reasonable input into a form that `pct` accepts. The remaining question is more about philosophy than correctness: - current behavior is strict pass-through and fails early - mapping would be more user-friendly and avoid a confusing hard error Technically, both approaches are valid. I agree that mapping `Etc/UTC` to `host` would be a reasonable UX improvement, as long as it’s documented and transparent. But i can say, in the fact, its not an "issue" by us or Proxmox, its an work by Design - why? Nobody knows expect the Dev :smile:
OVERLORD commented 2026-02-05 04:05:33 +03:00
Author
Owner
Copy Link

@ralfbergs commented on GitHub (Dec 15, 2025):

Technically, both approaches are valid. I agree that mapping Etc/UTC to host would be a reasonable UX improvement, as long as it’s documented and transparent. But i can say, in the fact, its not an "issue" by us or Proxmox, its an work by Design - why? Nobody knows expect the Dev 😄

Ok, so how do we take it from here? Check with the dev? Is it @remz1337 ?

@remz1337 , if you are the currently active dev for this script, could you pls check out this issue and let me know your view?

@ralfbergs commented on GitHub (Dec 15, 2025): > Technically, both approaches are valid. I agree that mapping `Etc/UTC` to `host` would be a reasonable UX improvement, as long as it’s documented and transparent. But i can say, in the fact, its not an "issue" by us or Proxmox, its an work by Design - why? Nobody knows expect the Dev 😄 Ok, so how do we take it from here? Check with the dev? Is it @remz1337 ? @remz1337 , if you are the currently active dev for this script, could you pls check out this issue and let me know your view?
OVERLORD commented 2026-02-05 04:05:37 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Dec 15, 2025):

That has nothing To-Do with the Script. I can increase the core (not in the next 4 weeks), but Like i said, its not an issue. Just write Host or your correct Timezone

@MickLesk commented on GitHub (Dec 15, 2025): That has nothing To-Do with the Script. I can increase the core (not in the next 4 weeks), but Like i said, its not an issue. Just write Host or your correct Timezone
OVERLORD commented 2026-02-05 04:05:42 +03:00
Author
Owner
Copy Link

@ralfbergs commented on GitHub (Dec 15, 2025):

That has nothing To-Do with the Script. I can increase the core (not in the next 4 weeks), but Like i said, its not an issue. Just write Host or your correct Timezone

Increase the core? Sorry, I don't understand... 🤷🏻‍♂️🤔

@ralfbergs commented on GitHub (Dec 15, 2025): > That has nothing To-Do with the Script. I can increase the core (not in the next 4 weeks), but Like i said, its not an issue. Just write Host or your correct Timezone Increase the core? Sorry, I don't understand... 🤷🏻‍♂️🤔
OVERLORD commented 2026-02-05 04:05:47 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Dec 15, 2025):

... build.func

@MickLesk commented on GitHub (Dec 15, 2025): ... build.func
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Implemented in VED waiting push to Main
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
in project pipeline
invalid
investigation
json
maintenance
needs triage
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
🛑 Failure to comply with the guidelines
No Label not a script issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#2166
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?