Is this software free of charge?
Yes, I like the software. It has come very close to just fitting into how I have things set up on my NAS. Still need to tweak a couple things.
I’m interested in the phone software. I mainly use an iPhone but I do have an Android tablet. I tried joining the iPhone app beta on TestFlight but it said it was not open to new users. Maybe it’s not approved yet?
Yes. Technically it is shareware but there is no mandatory cost.
@Silas - So a question for you regarding storage…
The default storage location for everything Rtorrent is in the QNAP Public folder. Once a download is finished it is linked/copied to the Media Library. But my Public folder is on a 2 TB NVMe drive which I don’t want filled up with media files. I tried putting the rTorrent storage tree inside my share Media folder but the software would not let me do that (put it inside the Media Library). Since I am using QuTS Hero, I ended up creating a new shared folder for the default Rtorrent file tree. But since in QuTS, shared folder = shared volume basically, am I right in assuming then that the software will copy everything from the Rtorrent tree to my Media folder. So I’ll end up with multiple copies? I really don’t want that.
Does Rtorrent copy across volumes or storage pools? Both the Media Library folder and the Rtorrent folder are in the same storage pool but QuTS considers them really separate volumes.
I have plenty of other questions regarding security and opening of ports on the NAS/router, etc. but I will read the docs first.
Thanks!
Ah exactly. An inverse of Shareware 
Let me clarify how path configuration, storage management, and copying/hardlinking work on QuTS hero.
1. Base Folder & Why “Public” Was Selected
In the settings of the program itself, you configure the base path. It is important to keep in mind that the base path is the location where the download folder resides, and you can fully configure this in the settings.
Because of this, you don’t actually have to select or use Public. Public was only selected because during installation or first launch, the app likely couldn’t locate default network shares (such as a standard Download share) and fell back to Public as a default. That is why it decided to create its initial base download folder there.
When you go into the settings, you can change this download folder—and it is definitely worth changing. You can plan your approach entirely and set this download folder to a dedicated new network share, for example, Rdownload.
2. Data Flow, Agents & The Vault
By the way, as a quick tip on how the data pipeline works:
- Processing: Data from the download folder is parsed by Movie Agent or Game Agent.
- The Vault & Seeding Protection: In the best-case scenario, files move into the vault where the
completecatalog is located. Why into the vault? Because while seeding is active, the data is kept in the basedownloaddirectory to protect you from ratio issues or unwanted data loss. - Media Library: From
complete, the data lands into your Media Library - only movie/tv category and it’s moved there. You can have as many Media Libraries as you wish.
3. QuTS hero (ZFS), Cross-Volume Behavior & Hardlinks
Regarding your question about cross-volume behavior on QuTS hero:
- ZFS Dataset Boundaries: On QuTS hero with ZFS, separate shared folders act as individual volumes. Data cannot be hardlinked across different ZFS volumes.
- Automatic Copy Fallback: If you use a different download folder located on a separate volume from your Media Library, hardlinks are not possible, so the system will automatically fall back to copying the files.
- Live System Status: You will be informed whether hardlinking is possible during the process. If you open the Media Library settings while downloading, you will see the full diagram come alive with animated graphs, giving you a live preview of downloading/incoming data and how routing through the
downloaddirectory is occurring.
4. Recommended Setup
To answer your question directly: yes, you should plan your setup so that you can later connect the folder you created to Plex or other media players.
Recommended Structure:
You can set up a single dedicated network share (for example, named Rdownload) that houses the full workflow tree on the same volume:
So if I understand correctly then, I should create a new shared folder/volume that holds both Rtorrent and my MediaLibrary. Then instead of copies, it creates the hard links.
Correct?
OK, so further question - we always tell people not to expose your NAS to the WAN (at least not trusting the NAS’s security and using a Container instead). We scream it loud and louder. But in order for all the functions of Rtorrent to work - you need to do some port forwarding. Is your server software secure? Does opening these ports put me or my NAS at risk?
Yes sir 
Yes, I completely agree that exposing public ports to the internet carries risks, but it always comes down to what the service is, how it works, and what your use case is.
Take Plex, for example. People often point out past attack vectors on media servers, but the primary reason to forward that port isn’t necessarily to share content with the whole world—it’s so you can access your own media remotely, because that’s the whole point of running your own server.
When you expose a service to the public internet—regardless of what it is—you are the one(?) who assumes full responsibility, never the software vendor. If a vulnerability or an attack vector is exploited, the blame doesn’t lie with the vendor; it lies with the decision to expose that surface. In an ideal world, there wouldn’t be any attacks, but we don’t live in one. Ultimately, you have to weigh the convenience against the risk and decide whether exposing your server is worth it for you.
That brings us to another critical use case: peer-to-peer protocols like BitTorrent.
Applications such as uTorrent (and BitTorrent clients in general) explicitly require inbound ports to be open so they can forward packets and directly exchange data with peers. That is simply how the protocol was designed to work. To handle this, these clients support automatic port mapping protocols like UPnP, NAT-PMP, and the modern standard, PCP (Port Control Protocol). If your router supports PCP, you don’t even need to manually set up port forwards; the protocol handles it dynamically.
My opinion:
Now, there is often advice floating around saying “always disable UPnP on your router.” In my view, taking a blanket approach like that is a mistake, especially for home users:
-
In a home/entertainment environment: Disabling UPnP completely can break direct connections. If you block it entirely, you often lose peer-to-peer connectivity, forcing your traffic to relay through third-party servers handling hundreds of thousands of users (similar to how some VoIP or chat apps work). That significantly degrades connection quality and performance. As an administrator of your own local network, you should know which client applications are running and what they are allowed to do.
-
In an enterprise environment: It’s a completely different story. For corporate networks, disabling UPnP is standard security best practice for entirely valid reasons. But applying that exact same corporate paranoia to a home entertainment setup is counterproductive.
Small explanation…
Finally, I want to issue a slight correction and walk back a bit on what I said earlier. While it’s true that we as users must take responsibility for securing our own infrastructure, let’s be real:
ultimately, the ones responsible for cyberattacks are the hackers themselves.
We just have to be cautious and protect ourselves in an imperfect world.
But don’t get paranoid.
Cheers!
Oh, I agree 1000%. I was hoping you could tell me that your server is more robust from an attack vector standpoint than say QNAPs.
I use a Mikrotik router and I saw somewhere you already listed the port forwarding rules for Mikrotik. I need to find that again! 
Very strange I do not use port forwarding (or upnp) and direct torrent traffic via selective routing through a paid anonymisier VPN, works just fine.
Oh downloading only works fine. He and I are talking about being able to serve as a peer.
I have no ports forwarded, nor would UPnP every be enabled on my router, and I have no issues being a peer.
Maybe I’m mixing up a use-case or it is because I am running different software.
If you are going to be a peer and allow incoming connections, then you have to have something forwarded. There’s no other way about it…
Well, to be fair, I don’t forward ports either. In fact, I don’t even use torrents myself. But I hear from “friends” who happen to be in elite, private closed trackers where maintaining a high share ratio and seeding long-term isn’t just a suggestion—it’s a religion. In those communities, people don’t exchange “torrents”; they exchange “content.”
At the end of the day, it’s entirely up to you whether you forward ports or keep your setup completely airtight. If you choose to lock everything down, that’s your call and nobody can tell you you’re wrong. But that approach simply doesn’t work on real private trackers. And I don’t mean “semi-private” public trackers that require an invite while actively pushing a VPN service they probably affiliate-link from. I mean truly private communities where long-term seeding and ratio requirements actually matter.
In those environments, open connectivity is vital. Honestly, properly exposing a listening port feels less like a risk and more like avoiding a form of digital self-flagellation—instead of castrating your speeds and choking your transfers down to a few megabytes per second through a VPN tunnel, you actually get to use your pipeline. Sure, Rtorrent16 even supports native ProtonVPN port-forwarding integration out of the box now, but that’s still capped by VPN overhead.
Rtorrent16 was engineered for serious scale—it’s designed to handle thousands of active seeds, leverage memory-caching mechanisms, and comfortably saturate line speeds up to 10 Gbps on high-end hardware.
If your main goal is just passive downloading behind a double-NAT/VPN setup without caring about connectability or seeding performance, your current unique setup works fine for you. But for heavy seeding and high-throughput environments, Rtorrent16 might just not be the right fit for your use case.
Depends on how you look at it. In my case I’m pretty sure the outbound connection from my local client initiates the registration and connection to the server to register as a peer and allows the connections to take place. In any case, I seed torrents. I have no port forwarding rules. I do not have UPnP enabled. It works, therefore “There’s no other way about it” may depend on how you define things.
Check out “passive torrenting”.
Well, if you are using an app that connects to a 3rd party server that handles all the inbound connections, then sure. The hole is opened from your side through to the server and you have a handshake securely initiated.
@dosborne @dolbyman Just to clear up a fundamental detail about how P2P connectivity actually works:
If both Peer A and Peer B have closed ports (no port forwarding, no UPnP, behind a standard NAT or VPN), they CANNOT establish a connection with each other at all. Period.
The only reason a setup with completely closed ports works for downloading or basic peer activity is because you are connecting exclusively to peers who do have their ports open. In other words, a closed setup relies entirely on the generosity and setup of other peers on the network who opened their ports so you can reach them.
On public trackers, with thousands of open peers, you might not notice the impact as much. But on tight, private trackers—where connectability between peers is critical to maintain ratios and distribute content efficiently—being non-connectable severely limits who you can seed to and chokes your overall performance.
So while a fully locked-down setup works for casual use, it essentially turns you into a passive peer relying on others to do the heavy lifting. That’s why open connectivity is necessary for high-throughput environments like Rtorrent16.
When you start a torrent, your client contacts a tracker to request a list of peers. After obtaining this list, it initiates outgoing connections to these peers to begin downloading. Peers can also learn about your client from the tracker (or from other peers) and attempt to connect to you. This bidirectional connection establishment allows peers behind NAT to communicate with others, as long as at least one of the two is publicly accessible.
So, is port forwarding necessary for torrenting? Not strictly, but it’s highly recommended. Without it, you can only make outgoing connections to publicly accessible peers, and in my experience, very few peers have public IPs–especially in regions like China. Having a public IP or properly configured port forwarding ensures that those NATed peers can reach you.
@dosborne Exactly, and that excerpt proves my point!
Connections only work if at least ONE peer has an open port. Since yours are closed, you can only make outgoing connections to peers who forwarded ports.
If everyone disabled port forwarding like you, no two NATed peers could connect, and the swarm would freeze. You’re basically relying on others keeping their ports open.
That works for casual downloading, but not for high-throughput seeders on Rtorrent16.
Fine. My comment was to point out a use-case that does work, contrary to:
For my purposes, in my use-case, it works with no forwarded ports. 
I guess as long as there is 1 persons out of x…
(Sorry, this is probably really off topic of RTorrent, which I have no direct knowledge of - but it does look interesting and I may investigate further one day)