strike

Thanks. I was working under the assumption that you were on a narrow screen like a phone, so I set a min width for the boxes, which seems to have worked. But it seems that somehow your screen/laptop is triggering the "mobile" view. I don't have that many screens to test with, but now that I know that you're on a laptop, I can see if I can reproduce it on my laptop, since I'm unable to reproduce it on my TV and phone. I totally forgot that I even have a laptop (I never use it, I like my 85" tv better..) I'll be back with a new dev version probably tomorrow. I just fixed @unabletoconnect 's issue at least. So we're getting close to a bug-free release pretty soon, I hope. :)

Thanks for the screenshots. I notice you are on the version from 2025.12.31-3. Can you try the latest dev version I posted a few posts back? My plan was to continue to work on the dev version tonight, but my VM started having weird issues that I have to fix first. But most likely there will be a new dev version out in the weekend, just have to fix my VM first. I would really like to know if your display issues still are presented in the current dev version though.

@unabletoconnect I've looked at this, and it could be that the file was in use/locked by another process, and when that happens, the script returns the size as 0. It tries to move the file, but fails. Since the file wasn't moved, the disk space hasn't changed. The script finds the same "best" file again, causing an infinite loop. I'll have to do some more testing tomorrow before I post a new dev version. Thanks for helping me test, btw it's much appreciated!

Thanks for reporting. I'll post an updated dev version later today.

I've pushed an update to the dev version now: https://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-dev.plg If you rolled back to the 2025-11-08 version, please back up your settings.cfg file in /boot/config/plugins/DiskSpaceManagement/ so that if you need to roll back to the old version again, you can copy that file back so you don't need to set up your settings again. @unabletoconnect @poto2 Please test the new dev version when you're able to, and tell me if the issues are fixed (should be). @rgreen83 Your issue should be fixed as well. I've tested it on both the grey and azure themes. I've also added a "stop script" button on the log tab. @Crimzon and anyone else with the "smashed screen" display issue. Please confirm if it's fixed now.

Here is the link to the old version for those of you who want to roll back while I'm working out the new bugs. http://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-2025-11-08.plg You'll need to set up your paths again if you decide to roll back. A new dev version will be posted very soon. And since I'm unable to reproduce your issues (except for @rgreen83 's issue) I need you to test it for me to confirm if it's working or not.

Glad someone likes the UI, haha.. 😊 When the bugs are fixed it will be a much better than the old one IMHO. Edit: I'm aware of the display issues on the Grey and Azure theme. You can switch to the black theme in the meantime. There's currently no stop command. But you can kill it by running this command I'll add a stop command in the next release, so that it stops after moving the current item.

Thanks for reporting. I'll look at it after work. 😊

Open up a terminal and run this command: kill -9 $(cat /tmp/dsm.running) && rm /tmp/dsm.running

@unabletoconnect @poto2 Which version did you get the error? I posted a link to a dev version, is it that one?

I'll take a look at it after work and also post a link to the previous version.

@Crimzon Can you please uninstall the plugin, install this dev version, and see if the issues are resolved? If it is, I'll push the update to all. Go to plugins-install plugin and paste this URL: http://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-dev.plg If you're still having display issues, please post a screenshot again.

Aight, I'll see what I can do. But I'm kinda working blind here since I'm not able to reproduce. BTW your screen looks very narrow, or at least your screenshot is. Is your screen vertical? Or is it a small screen?

Would be nice to know what's not working so I can fix it. Is it the same issue @Crimzon has?

Have you also tried in a private/incognito window to rule out any plugins? Could you please post a screenshot of the entire screen? And what color theme are you using? You can find it in settings-display settings

Are you using a custom theme or something? Is this on a desktop or on a mobile device? And what browser are you using? I'm using the black theme, and I'm unable to reproduce this. There is a minor display issue on some elements on the Azure and grey theme, but nothing like you described.

I agree with @bmartino1 For file sharing SFTP is the way to go. I like the SFTPGo app. You can connect using an SFTP app or use the webclient (set up a reverse proxy and/or tailscale and you can get to your data from anywhere). It also supports WebDAV. I gave up nextcloud years ago and never looked back.

Happy to hear your upgrade went well. You shouldn't have anxiety about upgrading. As long as you remember to make a backup of your flash drive before performing the upgrade, you can always roll back if necessary. You should always strive to stay up to date, as falling too far behind can make it more difficult to upgrade. If you have a hard time troubleshooting, it's smart to wait for a release or two when upgrading to a major version, as there always will be some small bugs in the first releases. But historically, it's pretty stable after that.

If you have multibit ECC it can correct too. I can't remember if single bit ECC does. I had multibit ECC in my old server, and it saved me multiple times from corruption. But I agree, it is more likely that data will be silently corrupted while in RAM than on a hard disk. If I were worried about bitrot, I would go for a server with ECC ram. Or use ZFS, preferably both. I have backup of my most important data, but most of my data is video files, which I don't have a backup of. But if a videofile gets bitrot, the most I would notice are some artifacts on playback in a scene or two. Pictures are more prone to corruption for some reason, and as a result, you may not be able to open the file at all. I have ECC RAM in my current server too, but it's "on-die ECC" which is not as good as normal ECC. But I chose to go for consumer-grade hardware when I upgraded my hardware last time. But personally, I don't worry that much about bitrot. I can restore important data from backup if I have to.

One more thing in unraids favor; the forum. After using unraid for over 10 years I think the best unraid feature is the forums! There's so many talented people here and everyone is very friendly, welcoming and eager to help. And I have to say, the mods do an fantastic job! I don't think they have to moderate to much,but you can see them in nearly every thread helping out. It's truly astonishing how well this forum works.

True that! Yeah, I guess it does.

There are a few, that's why I use it. Not for the IP's themselfs, but for other reasons. The only thing I use the IP for is ordering all my containers by them, so it's really easy for me to deploy a new container with a new IP. I just take the next IP in the list. My DHCP server is configured so I have plenty of IP's to choose from as they are outside the DHCP range. Ok, yeah, I don't need to worry about that. That's one of the reasons I use a dedicated IP. Maybe it's simpler for others and newcomers to go with the "default" setup, but funny enough, I think it makes it more complicated. But that may be because I'm so used to "my way" of doing things..

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.