starred/ProxmoxVE

Fork 0

mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-04-26 01:36:05 +03:00

[GH-ISSUE #10102] pihole LXC disksize config no longer big enough #2182

New issue

Closed

opened 2026-02-26 12:51:35 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 12:51:35 +03:00

Owner

Originally created by @nickmv5 on GitHub (Dec 18, 2025).
Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/10102

✅ Have you read and understood the above guidelines?

yes

🔎 Did you run the script with verbose mode enabled?

No response

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

pihole

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

n/a — LXC disk size config for this is bad

⚙️ What settings are you using?

Default Settings
Advanced Settings

🖥️ Which Linux distribution are you using?

No response

📈 Which Proxmox version are you on?

9.1.2

📝 Provide a clear and concise description of the issue.

Earlier today I had a total DNS failure on my pihole LXC (with Unbound option installed), only to find that disk usage on the pihole LXC was maxed out at 1.99GB/2GB.

Behavior I encountered:

Unbound root key file got corrupted (had to be replaced even after resizing)
Pihole config only partially loaded until resizing was completed (eg. local DNS records missing, and pihole effectively useless with Unbound failing upstream)

Even after resizing to 4GB, the bootdisk reports, on a relatively idle instance on my LAN, 1.79GB used of 2GB, so it’s already pretty close off a fresh reboot.

It appears that the LXC configuration for using pihole with the unbound option installed is simply insufficient. It might be worth changing this script to 3GB disk size or perhaps having a separate config option for the 2 services together that uses 3GB while pihole only needs 2GB.

🔄 Steps to reproduce the issue.

Use pihole LXC with Unbound option installed. No crazy configs or list sizes, we’re talking 600k domains, maybe 50 local DNS records, running on a home LAN with 50 total client devices (virtual and physical).

Observe disk space — it’ll be pretty low.

❌ Paste the full error output (if available).

n/a — I wasn’t able to grab any logs before reporting this

🖼️ Additional context (optional).

No response

Originally created by @nickmv5 on GitHub (Dec 18, 2025). Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/10102 ### ✅ Have you read and understood the above guidelines? yes ### 🔎 Did you run the script with verbose mode enabled? _No response_ ### 📜 What is the name of the script you are using? pihole ### 📂 What was the exact command used to execute the script? n/a — LXC disk size config for this is bad ### ⚙️ What settings are you using? - [ ] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? _No response_ ### 📈 Which Proxmox version are you on? 9.1.2 ### 📝 Provide a clear and concise description of the issue. Earlier today I had a total DNS failure on my pihole LXC (with Unbound option installed), only to find that disk usage on the pihole LXC was maxed out at 1.99GB/2GB. Behavior I encountered: 1. Unbound root key file got corrupted (had to be replaced even after resizing) 2. Pihole config only partially loaded until resizing was completed (eg. local DNS records missing, and pihole effectively useless with Unbound failing upstream) Even after resizing to 4GB, the bootdisk reports, on a relatively idle instance on my LAN, 1.79GB used of 2GB, so it’s already pretty close off a fresh reboot. It appears that the LXC configuration for using pihole with the unbound option installed is simply insufficient. It might be worth changing this script to 3GB disk size or perhaps having a separate config option for the 2 services together that uses 3GB while pihole only needs 2GB. ### 🔄 Steps to reproduce the issue. Use pihole LXC with Unbound option installed. No crazy configs or list sizes, we’re talking 600k domains, maybe 50 local DNS records, running on a home LAN with 50 total client devices (virtual and physical). Observe disk space — it’ll be pretty low. ### ❌ Paste the full error output (if available). n/a — I wasn’t able to grab any logs before reporting this ### 🖼️ Additional context (optional). _No response_

kerem

2026-02-26 12:51:35 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

@tremor021 commented on GitHub (Dec 18, 2025):

So, is anyone stopping you to increase the disk storage?

@tremor021 commented on GitHub (Dec 18, 2025): So, is anyone stopping you to increase the disk storage?

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

@nickmv5 commented on GitHub (Dec 18, 2025):

So, is anyone stopping you to increase the disk storage?

"Go fix it yourself" is objectively NOT the way to resolve the very real issue I filed a bug for.

But if you want to be backhanded/insulting to me and close the issue, that's fine. This is the last time I ever file a bug report to attempt to bring attention to an issue for this so-called "Community" (feels like the opposite).

I hope you remember this vividly when the next bug report gets filed repeating the exact. same. issue. But I guess that's users' fault and not the core script not being configured large enough right out of the box. /s

@nickmv5 commented on GitHub (Dec 18, 2025): > So, is anyone stopping you to increase the disk storage? "Go fix it yourself" is objectively NOT the way to resolve the very real issue I filed a bug for. But if you want to be backhanded/insulting to me and close the issue, that's fine. This is the last time I ever file a bug report to attempt to bring attention to an issue for this so-called "Community" (feels like the opposite). I _**hope**_ you remember this vividly when the next bug report gets filed repeating the exact. same. issue. But I guess that's users' fault and not the core script not being configured large enough right out of the box. /s

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

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

What's wrong with forking the project, swapping the 2 for a 4 in 2 places, and creating a PR? You don't even have to test anything.

@MickLesk commented on GitHub (Dec 18, 2025): What's wrong with forking the project, swapping the 2 for a 4 in 2 places, and creating a PR? You don't even have to test anything.

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

@tremor021 commented on GitHub (Dec 18, 2025):

This is not a bug, the application itself is filling up the space as it continues to do its job. If you reached default disk size we set, do 2 clicks in the proxmox UI and expand it....
Jesus Christ its really that simple....

This is what you SHOULD be doing for ANY container you're maintaining... This has nothing to do with us..

Also, how you saw "expand your storage" as a insult is beyond me....

@tremor021 commented on GitHub (Dec 18, 2025): This is not a bug, the application itself is filling up the space as it continues to do its job. If you reached default disk size we set, do 2 clicks in the proxmox UI and expand it.... Jesus Christ its really that simple.... <img width="533" height="182" alt="Image" src="https://github.com/user-attachments/assets/64afbbca-4bcf-4f2f-bb36-aa50bd29fc66" /> This is what you SHOULD be doing for ANY container you're maintaining... This has nothing to do with us.. Also, how you saw "expand your storage" as a insult is beyond me....

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

@nickmv5 commented on GitHub (Dec 18, 2025):

This is not a bug, the application itself is filling up the space as it continues to do its job. If you reached default disk size we set, do 2 clicks in the proxmox UI and expand it.... Jesus Christ its really that simple....
This is what you SHOULD be doing for ANY container you're maintaining... This has nothing to do with us..
Also, how you saw "expand your storage" as a insult is beyond me....

"so is anyone stopping you from" were the exact words, which you just left out I noticed. That was backhanded, you and I both know it, let's not sit here and play games. I'm curious -- when someone files a bug report for an app, do you ask then "so you can fix it yourself?", or do you verify whether it's an issue?

Whatever, if you guys consider it acceptable for a community script to set users up with an LXC doomed for failure within 1 month of install, then feel free to keep capped at 2GB. I am not an edge case, and it's more than reasonable to say "hey this needs more room right out the gate".

I was simply trying to bring awareness to the issue. To immediately receive a backhanded response AND then for you to sit here and pretend like it wasnt? Not a good look dude. Not a good look.

Read your reply back to yourself several times. if you cant see how it comes off, I dunno what to tell ya.
Good luck.

@nickmv5 commented on GitHub (Dec 18, 2025): > This is not a bug, the application itself is filling up the space as it continues to do its job. If you reached default disk size we set, do 2 clicks in the proxmox UI and expand it.... Jesus Christ its really that simple.... > > <img alt="Image" width="533" height="182" src="https://private-user-images.githubusercontent.com/58952836/528115457-64afbbca-4bcf-4f2f-bb36-aa50bd29fc66.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjYwODQ0MDEsIm5iZiI6MTc2NjA4NDEwMSwicGF0aCI6Ii81ODk1MjgzNi81MjgxMTU0NTctNjRhZmJiY2EtNGJjZi00ZjJmLWJiMzYtYWE1MGJkMjlmYzY2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEyMTglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMjE4VDE4NTUwMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTJjYzY0MTI4ZTY1Y2E0ZWIzMmFkNGQ3ZThmNTg3OWFkMTEwYmM2ZmYzOTA3OTE4NWE5MDIyNGQ4ZjYwZjZkYTcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.b8ouoBkHxwcsqPWYvR8OOdsxJjXGjdBzR4wCXkez_9g"> > This is what you SHOULD be doing for ANY container you're maintaining... This has nothing to do with us.. > > Also, how you saw "expand your storage" as a insult is beyond me.... "so is anyone stopping you from" were the exact words, which you just left out I noticed. That was backhanded, you and I both know it, let's not sit here and play games. I'm curious -- when someone files a bug report for an app, do you ask then "so you can fix it yourself?", or do you verify whether it's an issue? Whatever, if you guys consider it acceptable for a community script to set users up with an LXC doomed for failure within 1 month of install, then feel free to keep capped at 2GB. I am not an edge case, and it's more than reasonable to say "hey this needs more room right out the gate". I was simply trying to bring awareness to the issue. To immediately receive a backhanded response AND then for you to sit here and pretend like it wasnt? Not a good look dude. Not a good look. Read your reply back to yourself several times. if you cant see how it comes off, I dunno what to tell ya. Good luck.

kerem commented

2026-02-26 12:51:36 +03:00

Author

Owner

@tremor021 commented on GitHub (Dec 18, 2025):

I'm not sure why you keep arguing about something that is clearly YOUR job. Its your LXC, your host, your machine, your app. We just install it. Any further maintenance and work on it is up to you.

Stop asking us to do your job... Locking this now because its pointless to continue

@tremor021 commented on GitHub (Dec 18, 2025): I'm not sure why you keep arguing about something that is clearly YOUR job. Its your LXC, your host, your machine, your app. We just install it. Any further maintenance and work on it is up to you. Stop asking us to do your job... Locking this now because its pointless to continue

kerem referenced this issue

2026-02-26 13:34:02 +03:00

[PR #2182] [CLOSED] New Script: Watcharr #3593

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ProxmoxVE#2182

No description provided.

Rows
Columns