Rack 2 Reality

Tag: Docker on NAS

  • The Docker Containers I Still Use One Year Later on My NAS

    The Docker Containers I Still Use One Year Later on My NAS

    A year ago I wrote about the best Docker containers to run on a NAS. At the time, I was still in the “this is exciting, what else can I install?” phase. That phase is useful, and honestly it is part of the fun, but it is not the same as living with these containers day after day.

    After a year, my view has changed quite a bit. I no longer think the best Docker containers are always the most impressive ones. The best ones are the ones that keep solving a real problem without creating new ones.

    That sounds obvious, but it’s very easy to forget when you first set up a NAS. You start with storage, then Docker appears, then suddenly you are looking at dashboards, monitoring tools, media servers, smart home platforms, DNS blockers, download managers, and random utilities you did not even know existed two weeks earlier.

    This post is not another “install these 20 containers” list. I already wrote that kind of post n my earlier post on the best Docker containers for a NAS. This is the follow-up I wish more people wrote: what I actually kept, what I removed, what I still want to revisit, and what I would tell someone setting up Docker on a NAS for the first time.

    How Docker changed how I use my NAS

    When I bought my NAS, I mostly thought of it as storage. I wanted somewhere for backups, files, photos, and maybe some media. That’s still important, but Docker changed the role of the NAS completely.

    Instead of being a box that only stores files, it became a small home server. It could run Home Assistant for smart home automation, local apps that only I use, monitoring tools, and services that sit quietly in the background until I need them.

    That’s the part that’s hard to appreciate until you try it. A NAS with Docker is not just “storage plus apps”. It becomes infrastructure for your home. It can run things locally, keep data inside your own network, and remove some dependence on cloud services.

    But there is a catch. Every container you install has a cost. Not always a money cost, but a maintenance cost. It might use CPU, RAM, storage, network access, database writes, logs, or background activity. It might wake your HDDs when you expected the NAS to stay quiet. It might need updates. It might break. It might make your setup more complicated than it needs to be.

    That’s the lesson I learned over the last year. Docker is powerful, but it is also easy to overdo.

    My current rule: install for a problem, not for curiosity

    The biggest change in my thinking is that I no longer install containers just because they sound useful. I still like experimenting, but I now separate “interesting” from “actually worth running all the time”.

    A good container should do at least one of these things:

    • fix a genuine day-to-day annoyance
    • replace a cloud service I do not want to depend on
    • make the NAS more useful day to day
    • run quietly without constant maintenance
    • justify the resources it uses

    If it does not meet one of those, I probably do not need it running permanently.

    That does not mean you should never experiment. Experimenting is how you learn. But there is a difference between testing a container for a weekend and letting it become part of your permanent setup.

    Home Assistant: the one that genuinely changed my setup

    Home Assistant is the container that made the biggest difference for me.

    Custom Home Assistant dashboard running on a NAS with smart home controls, weather information, lighting zones, and sensor data.
    My Home Assistant dashboard running locally on my NAS. I recently rebuilt the layout from scratch, so it’s still very much a work in progress, but it already gives me a much cleaner overview of lighting, sensors, and smart home controls around the house.

    At first, I used it for simple automations. Motion sensors turning on lights, basic routines, and small quality-of-life improvements. Nothing too advanced. But even those simple automations changed how the house felt.

    The important thing I learned is that Home Assistant is only as good as the reliability of the devices and network around it. If a motion sensor is slow to report, or a light takes a second too long to respond, the automation feels bad even if Home Assistant itself is working perfectly.

    That was a big shift in how I thought about it. When something was delayed, my first instinct was to blame the automation or the container. In reality, the issue was often the communication path. Sensor to router, router to Home Assistant, Home Assistant back to the device. Every wireless step can add a little inconsistency.

    Once I improved my network setup, Home Assistant became much more dependable. A lot of that came down to reducing weak wireless paths and removing inconsistent connections between devices, which I covered in more detail in my post about WiFi vs wired consistency for smart home setups.

    That is why Home Assistant is one of the first things I would recommend if someone is interested in smart home control, but I would also warn them not to judge it too quickly. If it feels inconsistent, check the network and devices before assuming Home Assistant is bad.

    Who should install Home Assistant?

    Install Home Assistant if you have more than a couple of smart home devices and want them to work together instead of living in separate apps.

    It is especially useful if you have devices from different brands and want one central place for automations. For example, you might have SwitchBot devices, smart lights, sensors, and other equipment that all work fine individually but become much more useful when linked together.

    Who should skip it for now?

    If you only have one or two smart devices and are happy using the manufacturer apps, Home Assistant may be overkill. It is powerful, but it also rewards patience. You will probably spend time tweaking, testing, and learning how your devices actually behave.

    For me, it is worth it. But it is not a “set it and forget it in ten minutes” container.

    One thing I have added since then is Tailscale so I can securely access Home Assistant remotely without exposing my network directly to the internet. That alone completely changed how useful the setup feels day to day, especially when checking automations or devices while away from home. It also lets me use geofenced automations remotely without needing to pay for Home Assistant Cloud, which was a nice bonus. I will probably do a separate post on that because remote access is one of those areas where it is very easy to do the wrong thing if you are new to self hosting.

    Uptime Kuma: useful, but not essential for my setup

    Uptime Kuma is one of those containers that feels brilliant when you first install it. It gives you a clean dashboard showing whether your services are online, and it can notify you when something goes down.

    If you run a lot of services, it makes sense. If you host things for other people, it makes even more sense. It is also great if you are learning because it helps you understand what is actually running on your network.

    I liked it. I really did.

    The problem is that I eventually removed it because one of my monitoring containers seemed to be keeping my HDDs active. I am not saying Uptime Kuma is bad or that everyone will have that problem, but in my setup, I started caring more about disk activity, noise, and letting the NAS sit quietly when idle.

    That is something beginners often overlook. A monitoring tool is useful, but it also has to monitor things constantly. Depending on how it is configured, where its data is stored, and how often it checks services, it may create background activity you did not expect.

    Would I still recommend Uptime Kuma?

    Yes, but with context.

    If you are running several containers and want a simple way to see whether they are online, Uptime Kuma is excellent. It is one of the easiest monitoring tools to understand, and the interface is beginner friendly.

    But if your NAS is mainly for storage and you care about keeping HDD activity low, I would treat it as optional rather than essential. Install it, test it, and pay attention to whether your disks stay active more than expected.

    A good container can still be the wrong fit for your priorities.

    Portracker: helpful for learning, but I did not keep it

    Portracker was another container I liked because it helped me understand what was happening with my ports and services. When you are new to Docker, it is easy to lose track of what is exposed, what is mapped, and what is actually reachable on your network.

    That kind of visibility is useful. It gives you a better mental picture of your setup.

    But like Uptime Kuma, I eventually removed it. Again, the issue was not that it was bad. It was that my setup had changed. I no longer needed constant visibility enough to justify keeping every monitoring-style tool running.

    This is probably one of the biggest lessons from using Docker long term: some containers are great teachers, but not permanent residents.

    Portracker helped me learn. Once I understood my setup better, I did not need it running all the time.

    The DNS blockers: my unfinished business

    Pi-hole is the container I wanted to love, but I never got it working the way I wanted.

    To be clear, the problem was not that I could not start the container. The problem was that I could not get my network traffic to actually route through Pi-hole properly. In other words, Pi-hole may be running, but if your devices are not using it for DNS, it is not doing anything useful.

    That distinction is important for beginners.

    Installing the container is only step one. The real work is making sure your router, DHCP settings, DNS settings, and devices are actually pointing at it. If they are not, you can stare at a perfectly healthy Pi-hole dashboard while your network completely ignores it.

    That was my issue.

    At the time, I probably did not understand my network well enough to troubleshoot it properly. Since then, I have learned more about VLANs, mesh behaviour, DNS routing, and how devices actually communicate across the network. Because of that, I actually want to give Pi-hole another proper attempt.

    The appeal is obvious. Network-wide ad blocking, cleaner DNS control, and better visibility into what devices are requesting. For people who like understanding their network, Pi-hole is still one of the classic self-hosted tools.

    But I would not describe it as “install and done” for everyone.

    If your router makes it easy to set a custom DNS server, Pi-hole can be straightforward. If your router hides those settings, uses its own DNS behaviour, has awkward mesh or IoT network handling, or if your devices bypass local DNS, it can become frustrating quickly.

    That does not mean Pi-hole is bad. It means DNS is one of those areas where the container is only half the story.

    I also experimented with AdGuard Home briefly because I liked the cleaner interface and overall approach, but I never spent enough time with it to make a fair comparison. Right now, both of them sit in the category of “containers I still want to figure out properly” rather than containers I can fully recommend from long-term experience.

    That will probably become a future post by itself.

    My self-hosted recipe app: the thing that changed my mindset

    The most unexpected part of running Docker on my NAS was not installing someone else’s container. It was eventually hosting something I built myself.

    I created a local recipe app so I can store recipes in a way that works for me. It runs on my NAS and is available on my local network. It is not a huge commercial-style project, and that is exactly the point.

    It solved a specific problem I had.

    That changed how I looked at the NAS. It was no longer just a device for storage or prebuilt apps. It became a place where I could run my own tools.

    Self hosted recipe app running locally on a NAS with meal categories, recipe cards, and meal planning features.
    One of the unexpected benefits of Docker was eventually hosting my own apps locally. This recipe app runs entirely on my NAS and is used day to day for meal planning and recipe storage.

    This is one of the most underrated parts of Docker. You are not limited to whatever your NAS app store provides. If you can build or find a small web app, you can often run it yourself.

    Why this matters for beginners

    You do not need to be a professional developer to appreciate this idea. Even if you never build your own app, understanding that your NAS can host local tools changes how you think about it.

    Maybe it is a recipe app. Maybe it is a dashboard. Maybe it is a small tool for your household. The point is that Docker turns the NAS into something flexible.

    That is when the NAS stops feeling like “a hard drive on the network” and starts feeling like a small home platform.

    What I learned about NVMe and Docker

    Another thing I understand better now is where fast storage actually matters. I also touched on some of this in my UGREEN NASync DXP2800 review because Docker workloads changed how I approached storage much more than I originally expected.

    For bulk storage, HDDs still make the most sense. They are cheaper per TB and ideal for backups, media, archives, and general file storage.

    For apps and containers, NVMe can make the system feel more responsive. Containers often involve lots of small reads and writes, databases, thumbnails, logs, configuration files, and web interfaces. Those are the kinds of workloads where SSDs feel much better than HDDs.

    That does not mean everyone needs NVMe on day one. If you are building your first NAS, I would still prioritise enough HDD capacity first, especially if your main goal is storage.

    But if you plan to run Docker seriously, NVMe is worth considering. Not necessarily massive drives, but enough fast storage for apps, containers, and potentially cache.

    The key is not “NVMe is better than HDD”. The key is using each type of storage for the job it suits best.

    What I would install first today

    If I was setting up Docker on a NAS again from scratch, I would not install ten containers immediately.

    I would start with one container that solves a real problem, then build from there.

    For me, the first serious install would still be Home Assistant because it has had the biggest day-to-day impact. After that, I would consider a monitoring tool like Uptime Kuma, but I would pay close attention to whether it increases disk activity. Then I would revisit Pi-hole carefully, making sure the DNS routing side is actually working before judging the container itself.

    I would not install things just because they appear on every “best Docker containers” list.

    That is how you end up with a busy NAS, a dozen dashboards, and very little that actually improves your life.

    What I would avoid as a beginner

    The biggest mistake is installing too much too quickly.

    Every container adds another thing to understand. Where does it store data? Does it need a database? Does it expose a port? Does it need internet access? Does it write logs constantly? Does it wake the drives? How do you back it up? How do you update it?

    None of that means Docker is bad. It just means containers are not free from responsibility.

    I would also avoid exposing anything to the internet until you understand what you are doing. Running an app locally on your home network is one thing. Opening ports so you can access it from anywhere is completely different.

    For most beginners, local-only is the right starting point.

    What I still think Docker is best for

    After a year, I think Docker is best for three things on a home NAS.

    First, smart home control. Home Assistant is the obvious example here.

    Second, useful local services. This could be a monitoring tool, a DNS tool, or a small personal app.

    Third, learning. Docker teaches you a lot about networking, storage, ports, backups, persistence, and how services actually run.

    That learning curve can be frustrating, but it is also what makes the NAS more valuable over time.

    Final thoughts

    A year ago, I mostly thought Docker was a way to add cool features to my NAS.

    Now I think it is more about choosing what deserves to run permanently in your home.

    Some containers stayed because they genuinely improved my setup. Some were removed because they added more background activity than value. Others, like Pi-hole, are still on my revisit list because I know the idea is useful even if my first attempt did not work.

    That is the honest version of Docker on a NAS. It is powerful, flexible, and genuinely useful, but it is not about installing everything.

    It is about building a setup that solves real problems without creating too many new ones.

  • How I Actually Use a NAS Day to Day After the Setup Phase

    How I Actually Use a NAS Day to Day After the Setup Phase

    When people talk about NAS devices online, it usually falls into two extremes. Either everything is a shiny demo during the first week, or it turns into an over engineered home lab that barely resembles normal use.

    Both miss what actually matters long term.

    This post is about what ownership looks like after the excitement fades. When the NAS stops being a project and starts being part of daily life. What still runs, what quietly disappeared, and which decisions ended up saving time rather than creating more work.

    If you are trying to decide whether a NAS makes sense beyond the initial setup phase, this is the part that usually gets skipped.

    What runs 24 hours a day

    These are the services that stay on permanently because they deliver value without demanding attention.

    Automated backups (local first, cloud as insurance)

    Local backups are the foundation of my setup. Both my MacBook and my wife’s MacBook back up automatically to the NAS, and our iPhone photo libraries are included as well. Once configured, this becomes invisible. Devices back up when they are on the network, and there is nothing to remember or trigger manually.

    On top of that, I use Azure Blob Storage as an off site insurance layer, not as a requirement and not as something I would tell everyone to do.

    If you are running a four bay NAS with RAID and your data lives entirely at home, an off site backup is a nice to have rather than a must have. Local redundancy already covers most everyday failures. The cloud layer exists to protect against unlikely but high impact events such as theft, fire, or total hardware loss.

    In my case, I am storing roughly 3TB in the Cool tier with RA GRS enabled, meaning the data is replicated across regions. This currently costs around $65 to $70 per month, and the cost is dominated by geo replication, cool tier storage, and write operations.

    I have not had to restore from this backup yet, which is exactly how I want it to be. It exists purely for peace of mind rather than day to day recovery.

    The backups are handled using rclone, which gives me full control over scheduling, encryption, bandwidth usage, and retention policies. It also avoids vendor lock in. If I ever decide to move away from Azure, the tooling stays the same. I have a full breakdown of how this is set up in my rclone backup guide.

    Core Docker services

    A small number of Docker containers run continuously because they support everything else I rely on.

    Home Assistant is always running. It handles automations, device integrations, and state tracking quietly in the background. I rarely interact with it directly day to day, which is exactly the point. When automations are reliable, they disappear from your attention entirely.

    This pattern repeats across the setup. Anything that needs constant monitoring or manual intervention does not survive long term.

    What runs occasionally

    These are tasks that exist to maintain confidence in the system rather than provide convenience.

    Maintenance and administration

    I do not actively manage the NAS day to day, but I do check in periodically.

    This usually means:

    • Updating Docker containers when meaningful updates are released
    • Applying NAS firmware updates
    • Reviewing SMART data and disk health
    • Confirming backups are still completing as expected

    This happens infrequently, often weeks apart. The goal is not optimisation or performance tuning. It is reassurance. I want to know the system is still healthy and behaving as expected.

    Manual actions

    Some things are intentionally kept manual.

    I occasionally restore files from backups to confirm that restores actually work. This is not something I do often, but it matters. A backup that has never been tested is only theoretical protection.

    Container updates are another example. While critical updates are automated, some applications require manual updates or restarts. I prefer this balance. Automation handles the boring and predictable parts, while I stay in control of anything that could cause disruption.

    These interactions are rare, but deliberate. Over time, they build trust in the system rather than add ongoing work.

    What I am actively planning to add

    This is where the role of the NAS will expand beyond storage and background services.

    PoE security cameras

    I am preparing to move away from battery powered cameras and into a PoE based setup once UGREEN’s native cameras are available.

    At the moment, I use SwitchBot outdoor cameras. They are genuinely good cameras, but battery management is a constant friction point. I have already run USB power to some of them, and in one location that cable is far from ideal. It works, but it is not how I want fixed infrastructure to be installed.

    The plan is to introduce a dedicated PoE switch and run Ethernet to each camera location. CAT5e, CAT6, and even CAT7 will all work for PoE cameras. In practice, CAT6 offers a good balance of reliability, shielding, and future flexibility without chasing specifications that add little real world benefit. The priority here is consistency rather than speed.

    The appeal of the upcoming UGREEN cameras is not just PoE. Features like local AI processing, tight NAS integration, and removing subscription dependencies are exactly what I want. I have already covered those features in detail in my UGREEN SynCare AI Home Security NAS post.

    Once deployed, the NAS shifts from being storage and services into proper local surveillance infrastructure, with recordings kept on site and fully under my control.

    What I use it for beyond storage

    A family recipe web app

    One use case I did not originally plan for is hosting small, purpose built applications.

    I am currently building a simple web app to store and manage family recipes. Rather than paying for another subscription or relying on third party apps, it runs locally in Docker and does exactly what we need. No ads, no accounts, and no recurring costs.

    This is a good example of where a NAS quietly replaces paid services. The value is not complexity, but ownership and flexibility over time.

    Media streaming

    I originally used Plex for media streaming, but over time I moved to Jellyfin.

    Plex increasingly depends on user accounts, cloud services, and paid tiers. Pricing changes, features moving behind subscriptions, and past security incidents eventually made me uncomfortable with the direction of the platform.

    Jellyfin is fully self hosted. There is no account requirement, no cloud authentication, and no external dependency. Everything stays local. The trade off is less polish, but the benefit is full control.

    For my usage, that trade off is worth it. Media playback should not depend on an external service being online, a subscription remaining valid, or an account existing at all. Once everything is local, media becomes another background service rather than something that needs to be managed.

    Built in apps I still use

    While Docker handles most workloads, I do not avoid built in NAS features entirely.

    I actively use:

    • The UGREEN photo app for managing local photo libraries
    • The UGREEN UPS integration in the control panel for monitoring power events and safe shutdowns (US3000 UPS review)

    The difference is intent. I use built in apps where they add value and integrate tightly with the system, and Docker where flexibility matters more.

    What surprised me over time

    Stability changes how you think about performance

    I still care about performance, but I no longer obsess over it. The system has proven itself stable under real workloads, which means I spend less time watching metrics and more time trusting the platform.

    A NAS becomes background infrastructure

    Once configured properly, a NAS fades into the background. That is a good thing. It should feel closer to household infrastructure than a gadget you constantly interact with.

    Simplicity scales better than features

    The setups that lasted were the simple ones. Anything that added complexity without a clear benefit was eventually removed.

    Who this kind of setup is actually for

    This approach works well for people who want reliability first.

    If you enjoy constant tweaking, experimentation, and rebuilding, there is nothing wrong with that. Some people genuinely enjoy running a home lab as a hobby.

    For me, the NAS is not a hobby. It is infrastructure. I want it to work, recover gracefully when something goes wrong, and stay out of the way the rest of the time.

    When something goes wrong

    This is where the setup really earns its keep.

    Things do go wrong occasionally. Files get deleted by mistake. Power drops unexpectedly. A service stops behaving the way it should. The difference now is that these situations are no longer disruptive.

    If a file is deleted, it is a restore job, not a panic. If there is a power cut, the UPS handles shutdown cleanly and everything comes back up without intervention. If something looks off, I already know where to check and what a healthy system looks like.

    Even the worst case scenarios are planned for. Local backups cover day to day mistakes. Off site backups exist for events I hope never happen. Nothing relies on a single point of failure that would force me to scramble.

    That is the real outcome of this setup. Not that failures never happen, but that they stop being stressful when they do.

    Why this setup works long term

    Owning a NAS is not exciting long term, and that is exactly why it is worth having.

    Once the setup phase is over, it becomes dependable infrastructure. Files are protected locally, off site backups exist for worst case scenarios, automations run quietly, and services behave predictably.

    The goal was never to build the most complex setup possible. It was to build something that reduces friction over time.

    A setup like this saves more than money. It saves attention. Fewer batteries to charge, fewer subscriptions to track, fewer dashboards to check, and fewer decisions to revisit.

    That is the real value of a NAS once you stop treating it like a project and start treating it like infrastructure.

    If you’re thinking through a similar setup and want a second opinion, I’m always happy to talk it through!

  • How to Install Home Assistant on the UGREEN NASync Series Using Docker

    How to Install Home Assistant on the UGREEN NASync Series Using Docker

    Introduction

    After getting my UGREEN NASync DXP2800 set up, the next logical step was bringing my smart home devices under one roof.
    With its compact size, low power consumption, and full Docker support, the DXP2800 is a perfect hidden powerhouse for running Home Assistant.
    Rather than setting up another Raspberry Pi or a VM, I decided to run Home Assistant directly in Docker on the DXP2800 for a cleaner, more efficient setup.

    Quick Update:
    In my last post, I mentioned setting up lightweight apps like Pi-hole and Plex.
    After exploring it further, I decided to hold off on Plex for now — personally, I don’t need a media server since I’m not storing my own movies or shows.

    I’m planning to try setting up Pi-hole soon as a local DNS blocker. However, since I’m based in Japan, and local ISPs tend to lock down their routers pretty tightly, it might need a few extra workarounds. Either way, I’ll share how it goes — whether it’s a full setup guide or lessons learned trying to get it working.

    I also spent some time working on setting up an OpenVPN tunnel. The original plan was to host an OpenVPN server on Azure and route only my Fire Stick’s traffic through the VPN, without affecting the rest of my home network. After running into some technical hurdles, I decided to simplify things for now — I’m currently connecting my MacBook directly to the TV when needed, and planning to pick up an Apple TV 4K later to streamline streaming even further.

    As always, if you have questions, or there’s a specific setup you want to see covered, drop a comment below — happy to help!

    If you’re completely new to the UGREEN NASync series, you might want to check out my earlier post where I set up the NASync DXP2800 from scratch: Setting up the UGREEN NASync DXP2800 – A Beginner-Friendly Guide.

    Now that you know why Home Assistant is a great choice, let’s get it installed.

    Why Home Assistant?

    • Free, open-source smart home platform.
    • Supports thousands of integrations.
    • Centralises your entire smart home without cloud dependence.
    • Running it on the NAS keeps everything in one place and easy to manage.

    What You’ll Need

    • UGREEN NASync series unit
    • Docker installed (via App Center)
    • Bluetooth dongle (optional but recommended for Bluetooth devices)
    • I used the TP-Link UB500 — Bluetooth 5.0 and works flawlessly
    • Access to your NAS’s IP address and admin account

    Let’s move on to installing Home Assistant on your DXP2800.

    🖥️ The NAS used in this setup:

    💡 Need more bays?

    🧩 Bluetooth adapter I used for Home Assistant:

    These are affiliate links — if you decide to buy through them, it supports the blog at no extra cost to you. Thanks!

    Installing Home Assistant in Docker

    Option 1: Using the UGREEN NAS Interface (Recommended)

    UGREEN’s built-in Docker app makes container setup simple, even for beginners.

    Step 1: Install the Docker App

    • Open the App Center on your NAS.
    • Search for and install Docker.

    Step 2: Download the Home Assistant Image

    • Go to Docker > Image > Image Database.
    • Search for:
      homeassistant/home-assistant
    • Click Download to pull the image onto your NAS.

    Step 3: Create the Home Assistant Container

    • Go to Docker > Container > New Container.
    • Choose the homeassistant/home-assistant image you just downloaded from the Image Database.

    Configure the container:

    • Container Name: homeassistant
    • Network Mode: Host
    • Restart Policy: Always
    • Volume Mapping:
    • Host path: /docker/homeassistant/config (or your preferred location)

    Important: Enable Privileged Mode

    • When setting up the container, scroll down and tick Privileged Mode (this is essential if you want Bluetooth devices like SwitchBot to work).

    ✅ Once created, Home Assistant will launch and you can access it at:

    http://[NAS-IP]:8123

    If you prefer using command line for finer control, here’s how to set it up via SSH.

    Option 2: Installing via SSH (Optional / Advanced)

    Note:
    Depending on your NAS settings, you may need to prefix the following commands with sudo.
    For example, use sudo docker pull homeassistant/home-assistant instead of docker pull homeassistant/home-assistant.

    Prefer full control over your setup? Here’s how to do it manually via SSH.

    Step 1: SSH into Your NAS

    ssh [your-username]@[NAS-IP]

    Step 2: Pull the Home Assistant Image

    docker pull homeassistant/home-assistant

    Step 3: Run Home Assistant with Privileged Mode

    docker run -d \
  --name homeassistant \
  --privileged \
  --network host \
  --restart unless-stopped \
  -v /docker/homeassistant/config:/config \
  homeassistant/home-assistant

    ✅ Same result — Home Assistant running and Bluetooth-ready.

    Quick Comparison

    MethodBest ForProsCons
    NAS InterfaceBeginnersEasy, visual, no command line neededMight not suit users who want full CLI control
    SSH CLIAdvanced usersFull control, scripting flexibilityRequires SSH access and basic Docker knowledge

    Now that Home Assistant is installed and running, let’s move onto adding Bluetooth devices if you need them.

    Setting Up Bluetooth Devices like SwitchBot (Optional)

    If you want to control Bluetooth smart home devices, here’s how to set it up.

    Hardware Used:

    • Bluetooth Dongle: TP-Link UB500 (Bluetooth 5.0)

    How to Enable Bluetooth Support:

    1. Plug in the TP-Link UB500 to one of your NAS’s USB ports.
    2. Verify Bluetooth Detection:
      SSH into your NAS and run:
       lsusb

    Look for something like:

       Bus 002 Device 003: ID 2357:0604 TP-Link UB500 Adapter
    1. Home Assistant Detection:
    • Home Assistant should auto-detect the Bluetooth adapter after restarting.
    • You can then add integrations like SwitchBot easily.

    Pro Tip: If your NAS is tucked away in a cabinet or has weak Bluetooth range, using a short USB extension cable can dramatically improve signal reception.

    Adding SwitchBot Devices:

    • Go to Settings > Devices & Services.
    • Click + Add Integration, search for SwitchBot.
    • Follow the prompts to pair devices.

    First Steps After Installation

    Once Home Assistant was up and running, here’s what I did first:

    • Set up geofencing automations using the Home Assistant mobile app:
    • When I leave the house, my lights automatically turn off.
    • When I arrive home, certain lights turn on.
    • Created a few basic backups (snapshots) of my configuration, just in case anything went wrong.
    • Explored integrations like SwitchBot, lights, and sensors to start building out my smart home.

    Tip: Setting up a simple automation like geofencing is a great way to immediately see the power of Home Assistant in everyday life.

    Quick Troubleshooting Tips (Optional)

    If you run into small issues during setup:

    • Home Assistant can’t find Bluetooth devices?
      ➡️ Make sure Privileged Mode was enabled when creating the container, and confirm the Bluetooth dongle is detected with lsusb.
    • Can’t access Home Assistant web page?
      ➡️ Double-check the network mode was set to Host, and verify the container is running.

    Wrapping Up

    Running Home Assistant on the UGREEN NASync is a perfect way to centralise your smart home — simply and reliably. Thanks to Docker and a small Bluetooth dongle, I was able to control everything from Wi-Fi devices to SwitchBot sensors without needing multiple hubs or additional hardware.

    I’m planning to spend a bit more time exploring Home Assistant properly before posting anything detailed about it. No point rushing into features without understanding them fully.

    In the meantime, I’m looking at setting up a reliable NAS backup system — aiming to use Azure as a cloud destination to protect my data. If all goes well, I’ll share a simple guide on how to back up your NASync to Azure soon.

    As always, feel free to drop a comment if there’s something you’d like to see covered!

  • Setting Up the UGREEN NASync DXP2800: Step-by-Step Initial Configuration Guide

    Setting Up the UGREEN NASync DXP2800: Step-by-Step Initial Configuration Guide

    The UGREEN NASync DXP2800 is one of the most accessible NAS options for first-time users, and setting it up is refreshingly simple. In this post, I’ll walk you through the initial setup steps I took — from powering on to creating a storage pool — with commentary on RAID choices and a few tips I picked up along the way.

    What’s Included in the Box

    • UGREEN NASync DXP2800 unit
    • Power adapter
    • Ethernet cable
    • Screws (for 2.5″ drives)

    The NAS has the following ports:

    • 1x 2.5GbE LAN port (back)
    • 2x USB 3.2 Gen1 ports (back)
    • 1x USB-C 3.2 Gen1 port (front)
    • 2x USB 2.0 ports (back)
    • 1x HDMI (currently not in use)
    • Power button and reset button

    Make sure to connect the NAS using the included Ethernet cable for the most stable setup experience.

    Looking to pick up the NAS I used in this guide?

    💡 Need more bays? UGREEN also offers higher-capacity models:

    These are affiliate links — if you decide to buy through them, it supports the blog at no extra cost to you. Thanks for your support!

    Step 1: Power On and Detect the NAS

    Before you start, make sure your NAS is connected via Ethernet for the most reliable connection. It’s also worth checking for any available system updates once you’re in the dashboard — UGREEN recommends updating UGOS Pro early on to avoid compatibility issues, especially if you plan to use SSD caching or Docker later.

    As soon as the NAS is powered on and connected to your network, it appears in the UGREEN NAS app. It can take a few minutes for the device to be detected. However, if it doesn’t show up automatically, you can register it manually by scanning the QR code located on the bottom of the device.

    If it doesn’t appear straight away, you can scan the QR code on the bottom of the NAS to register it manually.

    Step 2: Name Your NAS & Accept Terms

    Once detected, the app prompts you to name your NAS and accept the standard user agreement and privacy terms.

    Give your device a unique name to help distinguish it on the network.

    Step 3: Register Your Email (Recommended)

    While you can skip this, I recommend linking your email for access to UGREENlink and system alerts.

    Registering your email enables remote access and alerts for any system issues.

    Step 4: Enable Remote Access

    I enabled UGREENlink, which gives you remote access to your NAS — useful if you want to monitor or transfer files while away.

    Remote access lets you securely manage your NAS from anywhere.
    UGREENlink remote access lets you securely manage your NAS over the internet. Your NAS name becomes your UGREENlink ID, which you can use from the web or mobile app.

    Step 5: Create Your Storage Pool

    Before you begin, ensure the NAS is powered off when inserting any drives. The DXP2800 uses a tool-less tray system for 3.5″ drives, which makes installation quick and simple. For M.2 SSDs, be cautious as they slot in internally and require careful handling.

    Here’s where you’ll select the drives you installed. I had two 7.2TB HDDs and two 1TB NVMe SSDs.

    You can mix drive types, but it’s best to separate HDDs and SSDs into different pools.

    I opted to configure my HDDs into a single RAID 1 array for redundancy. RAID 1 mirrors the data between the two drives, so if one fails, the other still has all your files. It’s not the most space-efficient, but it offers peace of mind.

    For the SSDs, I chose a Basic (non-RAID) setup for now — mainly because I plan to use them for apps or caching later. I didn’t see much benefit to mirroring them at this stage, especially since I’m not storing critical data there yet.

    RAID 1 for HDDs and a basic SSD pool gives a good mix of reliability and flexibility.

    Step 6: Format and Create Volume

    Once your storage pool is created, the next step is formatting the drives and setting up a volume. This is where you choose between Btrfs and ext4, the two available file systems.

    I chose Btrfs for my HDDs because it supports advanced features like snapshots, built-in data integrity checks, and efficient storage management — all of which are helpful if you’re storing lots of data or want more control over versioning and recovery. It’s especially useful in a home NAS setup where accidental deletion or corruption is a concern.

    For the SSD pool, I went with ext4. While it lacks the bells and whistles of Btrfs, it’s lighter on resources and has a long-standing reputation for reliability and performance. Since I’m planning to use the SSDs for running apps and temporary data, ext4’s speed and lower overhead made more sense.

    Here’s a quick breakdown:

    • Btrfs Pros: Snapshots, checksums, automatic error correction, efficient disk usage
    • Btrfs Cons: Slightly more system overhead, slower write performance than ext4 in some cases
    • ext4 Pros: Fast, low overhead, extremely stable
    • ext4 Cons: No native snapshots, no checksumming or automatic correction
    Btrfs is great for snapshots and folder-level protection. ext4 is a better fit for app containers or temporary storage.

    Before confirming, the system will warn you that all existing data on the drives will be erased.

    Once confirmed, your drives will be formatted and the volume created.

    Step 7: Review System Usage

    After setup, you’ll be shown a breakdown of how your drives are being used. In my case, the system reserved about 15.2GB on one of the SSDs — this includes operating system files and essential services needed to run UGOS Pro.

    This is completely normal, especially on Btrfs volumes where a bit more space is allocated for things like snapshots, metadata, and system overhead. You may also notice:

    • Slightly less available capacity than expected
    • Reserved space depending on your file system and RAID choice

    This screen is a great checkpoint to understand how your storage will behave moving forward:

    • Btrfs can accumulate snapshots and logs, so it’s worth checking the system status occasionally
    • SSDs used for apps (e.g. Docker) may fill quickly if large containers or image caches build up

    You can always check system usage later under the Storage section of the dashboard for a more detailed view.

    Storage overview shows space used by the system, available space, and reserved capacity.

    Final Thoughts

    The DXP2800 offers one of the smoothest NAS setup experiences I’ve used. From unboxing to configuring storage pools, everything was laid out in a way that’s friendly for first-time users. The guided setup process is clear and surprisingly quick.

    I’d recommend enabling two-factor authentication early on to help secure your admin account — it works with any standard authenticator app, and I opted for Microsoft Authenticator since I already use it elsewhere.

    If you’re planning to share the NAS, take advantage of personal folders or set up user-specific access permissions. It’s an easy way to protect privacy and organise data effectively.

    While RAID 1 is a great way to add redundancy, don’t rely on it as your only backup. It’ll help if a drive fails, but it won’t protect you from accidental deletion or file corruption.

    Finally, take note of the reset button behaviour: a short press restarts the system, while holding it down for 10 seconds resets it to factory settings — useful if you ever run into serious issues.

    Next time, I’ll walk through installing Docker and setting up lightweight apps like Pi-hole and Plex to unlock more potential from the NAS.

    Have questions or planning your own setup? Drop them in the comments — always happy to help!