Up and running.

[wardbryan3]

Hey guys just wanted to say thanks for this awesome software!

I am up and running now with 2 4TB WD blues and in the process of transferring data from my 22TB WD Red so it can join the party.
Current specs:

Motherboard: SUS H87M-PLUS (mATX) CPU: Intel Core i7-4770 (4C/8T, 3.4GHz)
RAM: 8GB DDR3 (2×4GB, 2 free slots)
OS drive: Samsung SSD
Storage: 2× 4TB HDDs + 500GB HDD

Working great so far but I am having some issues with firewall settings (probably a me issue) any plans on adding firewall setting to the UI to manually open ports ?

Also id be interested in helping on the project, if you guys have any simple issues let me know and I'd love to take a swing!

[fenio]

Welcome aboard, and thanks for the kind words — that i7-4770 box will chew through a 22TB Red just fine. 🎉

On the firewall: tell me more about your case — what are you trying to reach that isn't working, and what feels missing? Is it an app you deployed or one of NASty's own shares, and are you hitting the host port directly or going through the built-in ingress? With those details I can tell you exactly what's going on and whether it's something we should expose better in the UI.

On helping out: absolutely, would love that. An easy place to start is the Help & Glossary — always room for clearer wording and new entries. And honestly, just telling us what's wrong is a real contribution too: if something annoys you or feels off while you're using it, file it. That kind of feedback is gold. Open an issue (or reply here) for anything you want to take on and I'll help you scope it.

Thanks again for kicking the tires! 🖤

[wardbryan3]

Specifically, I was attempting to run multiple docker containers from one compose, and it was only opening one port, thus breaking access to all but one app, I was able to open them manually, but because this is nix based I couldn't figure out how to make it survive reboots. My solution was just breaking them into their own apps. That has solved the firewall problem for me for now. Something to consider though. Thanks for your response!

[fenio]

Thanks for the details — I dug into what you experienced, and it comes down to two things working as currently designed:

1. The web ingress creates one route per app. /apps/<name>/ points at your stack's first published TCP port — the model is "an app has one entry point". A compose stack with several web services publishes more ports, but only that first one gets a link.
2. NASty's firewall deliberately doesn't manage app ports. For apps on normal (bridge) networking, Docker publishes the ports itself and they're reachable at IP:port regardless of the firewall. The exception is network_mode: host — those ports land directly on the host, where the firewall is default-deny, and manual nft edits get overwritten because the engine owns and rebuilds that ruleset.

To understand which of these you actually ran into, could you share the compose file (or just tell us the network mode), and how you were reaching the services — through NASty's app links, or directly via IP:port?

And the most useful thing you could tell us: what would have made your life easier here? For example: per-service links in the UI for one compose stack, the engine handling ports for host-network apps automatically, a way to manage ports on the Firewall page — or something else entirely. Whatever fits your actual workflow best is what's worth turning into a feature request.

[wardbryan3]

version: '3'
services:
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    ports:
      - 9696:9696
    volumes:
      - /opt/arr/prowlarr:/config
    restart: unless-stopped

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    ports:
      - 8989:8989
    volumes:
      - /opt/arr/sonarr:/config
      - /tank/media/tv:/tv
      - /tank/downloads:/downloads
    restart: unless-stopped

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    ports:
      - 7878:7878
    volumes:
      - /opt/arr/radarr:/config
      - /tank/media/movies:/movies
      - /tank/downloads:/downloads
    restart: unless-stopped

  rdtclient:
    image: rogerfar/rdtclient:latest
    container_name: rdtclient
    ports:
      - 6500:6500
    volumes:
      - /opt/arr/rdtclient:/config
      - /tank/downloads:/downloads
      - /tank/media:/media
    restart: unless-stopped

That was my compose. Pretty basic I think.
I was reaching them through ip:port

nft add rule inet nasty input tcp dport xxxx accept  

Was how I would open them, but then obviously on reboot they closed.

I just think having manual firewall settings in the ui would make things helpful overall. (i.e a way to manage ports on the Firewall page)

Like I said, I switched each app to it's own container, and now it is working perfect.

[fenio]

Glad it's running well! One thing worth knowing for the future: splitting the stack shouldn't have been necessary. On normal (bridge) networking, Docker publishes every ports: mapping itself, and those published ports bypass NASty's firewall entirely — so all four services in your original compose should have been reachable at ip:port as one app. That also means the manual nft rule you added couldn't have been what fixed it (it only affects ports bound directly on the host) — most likely some of the services simply weren't up yet when you tested; with four containers in one stack, one crash-looping service is easy to miss. If you ever fold them back into one compose and something's unreachable, docker ps (the PORTS column) and the app logs in the UI will show the real story. The one-ingress-link-per-app limitation from my earlier reply still stands, but plain ip:port access doesn't depend on it.

Your firewall ask is fair regardless, and it's on our radar: user-managed port rules on the Firewall page — the supported, reboot-surviving version of your nft one-liner. Where it genuinely matters today is network_mode: host apps, whose ports do hit NASty's firewall. I'll link the issue here if/when we pick it up.

[wardbryan3]

Hey just gonna keep the contribution chat here. Two things I have been thinking about since my little PR.

1. I think having a search feature inside the help page would be super helpful. I think I would be capable of implementing it as well, just wanted your ideas on scope and if it was something you were interested in.

2. I have a decent amount of experience in building documentation websites using docusaurus. If that is something you'd be interested in, I would love to build that out in my free time.

[fenio]

1. Search for help page sounds reasonable. If you can provide PR for that I'll be happy to merge it.
2. I'm honestly not sure how much website, forums etc do we need at this point of life of this project. I mean I don't even know who is the target for this project. I started it to fulfill my personal needs... now we've got users. I guess it's up to users what else should we implement, introduce ;)

I'm open for whatever community (big word) wants.