You are lucky in a way that OMV has a fantastic documentation suite. it is not too long, and I recommend reading it cover to cover, as well as the omv-plugins and omv-extras documentation, skipping over anything that’s not interesting, but seeing that it’s there for future reference.

OMV is interesting to me because it gives you a gui that lets you do many difficult or advanced things fairly quickly, but it is not always clear what all the options do, and things don’t always work as expected. But the documentation will lead you well.

My advice is start slow, stick to the garden path (don’t try anything custom or unusual), and frequently browse the forums.

First and foremost: Do not expose your host system or the OMV admin interface to the internet. Ever. Doing so is only asking for trouble. Only expose services that have been properly isolated from the rest of the network and host system. Everything else you can access via VPN, or locally.

Secondly: OpenMediaVault beginner’s guide by DB Tech. Him, Craft Computing, Hardware Haven, and a few others whose names currently escape me, are all solid sources for learning how to host things at home.

After OMV, I would start with learning Docker and other containerization methods, and VMs.

I have no experience with OMV specifically, but generally making things accessible from outside your house means exposing it ti the internet.

However, what you can do is to only expose an openvpn port, so that to gain access as if you were at home you could connect via o0envpn first.

I have used OMV for years. Great system.

I remote in using zeroTier.

It’s installed on the OMV server, and I have it on all my devices.

That puts all my devices on a virtual “local network” so I can explore my shared folders, log into the OMV admin panel, etc, anywhere in the world.

Has been working beautifully for me, for years.

I hope that helps.

But I’m a bit lost which approach and tools to use without exposing and making my NAS vulnerable on the internet.

You’re looking for a reverse proxy;

*.domian.dev {
        encode zstd gzip
        @jelly host jelly.domian.dev
        handle @jelly {
                reverse_proxy {selfhost_ip}:{port}
        }
        @ping host ping.domian.dev
        handle @ping {
                respond "pong!"
        }
}

Running caddy like this directly connects your jelly.domain.dev domain to your selfhost ip on a specific port. From within your selfhost you ensure that you’re only allowing in the IP of the VPS, so no one can else can directly connect.

Works great. I use this myself. I have a local NAS (with media) and run a jellyfin server from my PC (to use my GPU for transcoding). The jellyfin server only allows 1 remote IP (my VPS), and local connections. The local jellyfin server can be accessed via my domain at jelly.domain.dev.