strike

Macvlan solves that, and the macvlan issues that were on the previous versions have been resolved. So if you need it, you can use macvlan. I've never had an issue with it. You can't deploy a container if you have port conflicts; it won't let you. Even if you have a reverse proxy, you can't deploy a new container with port conflicts.

Aaah, he meant it that way.. Then I understand, I thought maybe I missed a memo or something.

That's the first I'm hearing of it. I'd like to know why? Most of my containers have their own IP on the br0 network, for security reasons, and no need to change ports. I don't enable host access to custom networks, so even if my container somehow has malicious code and tries to break out of the container, it can't reach the host.

You need to change the name of your current container first, then you can install the same container again. Or if that app has multiple authors, you can just choose a different author of the same app, so you don't need to rename your current container.

Please update the plugin again. I decided to revert to using awk for the calculations, so we're not dependent on any packages.

Ah, it's because you don't have bc installed; it's used for the calculations of space. I'll see if I can either include that or revert to the previous method of calculating the space, which I believe used a different method.

UD should be able to format to NTFS now, I believe. Or just do it in windows.

Are you sure it's really hardlinked? Can you do this command and post the output ls -al /mnt/mircache/sorted/Assuming you have the 1234.7z there still, or any other files you have tried to hardlink

Looks like I was wrong regarding the open port. But it's an open issue here, might have something to do with docker? https://github.com/rogerfar/rdt-client/issues/296

The "T" in RDT stands for Torrent. At least that's what it says here: http://github.com/rogerfar/rdt-client, and like I said, when torrenting, you need an open incoming port to get the most speed. But I haven't tried it, so it might be different, but I doubt it. If it uses the torrent protocol, it should be the same as any other torrent client.

I haven't really tried RDT, but like with all torrent clients, it needs an open incoming port to be able to get full speed potential. If you don't have an open incoming port, downloads will be slow. Also, make sure your downloads go to an ssd pool.

Pushed the new update; it should migrate your settings from the old version. Enjoy, and have a Happy New Year! :) 🎆

This indeed seems to be the issue. I don't use PIA or wg, but is the PIA wg generated token for an endpoint always the same? If so, you can just edit the wg0.conf file yourself and add the token to the public key. You should, in any case, delete the wg0.conf file again since you posted your private key in the screenshot.

You can't hardlink across different filsystems/volumes/shares. Downloads and sorted are two different shares. It need to be within the same share.

@Crimzon And anyone else who follows the thread. So I decided to look at your suggestion right away, as I had nothing else to do (other than gaming BF), and I've been hard at work implementing it. And I decided to add a major facelift as well, while I was at it. Here is a sneak peek at what the plugin will probably look like when I'm finished, with a few minor tweaks. With browsable shares, drag and drop to prioritize move order instead of a comma-separated list of libraries. etc. I still have a few kinks to iron out, but I like how it turned out visually, compared to what it used to look like.

Have you enabled this setting in Settings-Docker?

So I have discussed this a bit, and I might have been convinced that this is possible to implement safely. Long story short, as long as my script never includes the /mnt/user/ in the rsync command, it should be good. So the UI is just a pointer, but in the backend, it is still the same logic. To be even safer, I could add a final validation check before the move that just exits and logs it if it sees /mnt/user/ anywhere in the rsync command. I'll look at this some more and see if I can implement it. I'm more hopeful now than I was before, and it will improve the plugin a lot. I might have overcomplicated things in my head. The rsync command is really the core command here, which does the move part. And if /mnt/user is never passed to that command, it will be safe. I'll come back to you with that ZFS fix first, so you can test, as I think I know where the issue is. It would be nice to have solved that too, as I'm not able to test the fix myself.

You need to do a new config, steps here: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/removing-disks-from-array/#removing-data-disks

Supermicro motherboards sometimes interpret low fan speeds as a fan failure, which causes all fans to spin up to 100% (fan "panic" mode) until the perceived "failing" fan's speed increases. You need to check and adjust the lower non-recoverable (LNR) and upper non-recoverable (UNR) fan speed thresholds. Either via IPMI or maybe use the fanctlr plus plugin as I mentioned (you might need to disable IPMI if possible), install the system temp plugin to monitor temps. Since this is a fairly new server, I assume there is no dust in the fans and the server itself? Edit: Have you installed the IPMI plugin by the way, and you're not able to connect with that? Been a while since I replaced my SuperMicro board, but when I used the IPMI plugin, I didn't need to set it up with a network connection.

I always appreciate suggestions that can improve the plugin, so thanks for that. I understand, I want this myself to be honest, but it's not that simple. I don't know how long you've been using unraid, but if you been using it for a while, you might know that there are two types of shares in unraid, user shares and disk shares. Most users don't even know that disk shares exist, because they're not enabled by default, and there's a good reason for that. And that's the "user share copy bug" which I explained in an earlier post. When only the user share is enabled, the user only sees /mnt/user/share, but when disk shares are enabled, all disks are also exposed, so in addition to seeing the shares, they also see all the disks in the file manager, like /mnt/disk5/share. And here is the issue I explained earlier: the problem is when a user copies/moves something from /mnt/disk5/share to /mnt/user/share or vice versa, this can lead to data loss and is the reason disk shares are not enabled by default. So the new users don't make this glorious mistake that it is. So in order for the plugin to have checkboxes so the user can just check their shares, it needs to expose the directory tree in the filesystem. And if both types of shares are enabled, they will see their user shares and all the disk shares. But normally, they will only see their user shares. So, say a user then selects /mnt/user/movies instead of /mnt/disk5/movies, the script would then somehow need to strip out the /mnt/user part and replace it with /mnt/disk5/movies. Or else there may be data loss. Everyone knows that user error happens all the time, and that's fine if it's their OWN fault. But I won't let it be MY fault just because of a bug in my script.. I would, of course, test it myself if I made the change (and I won't, unless somebody who knows unraid well convinces me that this is possible without exposing the directory tree). And everyone also knows, bugs happen all the time. Even if there was no bug at the time or in the past, there could always be a bug in the future. I would literally leave the internet and maybe move into the woods, never to be seen again, if somehow my script were the reason someone lost gigabytes or terrabytes of irreplaceable data. So yes, I will rather sacrifice a little convenience for a little more complex system for the user, if that helps keep their data safe. And the way it is now, there is no chance the script mistakes /mnt/user/movies for /mnt/disk5/movies. And you can still add how many shares you want. Since there are only three types of libraries, that decision made the most sense to me. But it might be possible to improve this based on how many shares are configured instead of libraries. I'll look into this and see if it makes sense. This one should be doable, but there might be usecases where a user wants to exclude disks that are not already excluded in the share settings for whatever reason. Then the already implemented solution is better.

Thanks, I'll look into it and see if I can come up with a fix you can test.

I'll answer this one in a few, dinner first :)

How does a dataset look like? Is it ounted like And what does a dataset look like? Is it a seperate mountpoint like with unassigned devices which uses /disks/?

Ooh, that's going to be a hard one for me to test since I don't use ZFS and thus the plugin hasn't been tested for that. Can you please provide a screenshot of the top directories on one of your disks?

Sound like you need to adjust the threshold for the fans. Since IPMI is out, you can try the fan ctrl plus plugin. I can't remember if it has a logging feature. What MB is it? If you have been messing with IPMI and maybe reset the BMC, that might the reason for the revving and you need to adjust the thresholds for the fans.