Rysz

Best post the diagnostics package now, hopefully there'll be a log this time. Was mergerFS disabled now?

Looks good to me - and you're running this through array_start.sh or array_start_complete.sh, I'm guessing? Something definitely shutdown your server before 02:45am, because the log starts with a server boot at 02:45am. Did you notice any parity checks or anything that would indicate an unclean shutdown has happened? Honestly if you changed nothing on the mergerFS scripts and they worked since December... I'd start looking at the GPU driver or a general RAM issue; might be worth running an extended memtest. ... to see if your RAM experiences any troubles after (x) hours of testing ... But @JorgeB is definitely more experienced at general support than me, so take this with a grain of salt. I don't think mergerFS is causing this, but as suggested I would try disabling it first and see if the problems still happen.

Yes, that's definitely a good idea, was already thinking a step further there. 😄

Can you please post the mergerFS scripts where you are setting up your mergerFS mounts? I see no actual errors regarding mergerFS, but let's see your scripts just to be sure. 🙂 mergerFS garbage collection is normal and occurs every 15 minutes by default (according to manual). Also... the log posted starts with a system reboot at 02:45am - did you do this reboot? ... or did the system crash and reboot itself? Since you say trouble started at 02:50am. ... 02:50am would be after that 02:45am reboot, so was it a crash or user-triggered reboot? Also... just to provide a timeline here - since you say the troubles started around 5 days ago: The mergerFS backend (the actual binary) has last been updated 26/03/2024. The mergerFS frontend (calling your mergerFS mount scripts) has last been updated 26/04/2024. Those frontend changes have been minor, only introducing a timeout so that array start cannot get stuck. So both these updates would have been way outside of the 5 days where you experienced trouble... But please do post your mergerFS mount scripts nevertheless, you never know! 🙂 @JorgeB: Seems more like a general system problem (perhaps RAM-related?) to me. It's also weird that diagnostics did not include a syslog, perhaps some problems writing to the rootfs (RAM-)disk? Also the user said /mnt itself was inaccessible, that directory should always exist regardless of any mounts being there.

Edit: I just saw your other support topic, let's continue this there for sake of completeness:

What do you mean?

No, because this will also kill the power of the UPS instantly and result in an unclean shutdown on all your clients and server. Always use only this command to trigger the NUT shutdown routine: It ensures a clean shutdown of your clients and your server, will also disable the UPS power (if that is configured in the GUI) after the clean shutdown and start the UPS again when the power is back. upsmon -c fsd

Use this command to start the NUT shutdown routine now: upsmon -c fsd The command you posted would result in an unclean shutdown because it would kill the power instantly.

Is your UPS physically connected to your UNRAID server or your Synology NAS?

Sorry, I can't provide support for usage cases outside of manufacturer's specifications. For safety reasons and from experience I'd also strongly advise against using any different battery capacity than those your UPS was rated for by the UPS manufacturer. The electrical mechanisms in the UPS may not safely be able to charge and/or discharge the higher capacity battery you are using, which may be hazardous for several reasons (fire, electrical shock, ...)

Thanks, but the point of this feature request is to be able to configure this on a per share basis through the GUI.

Hey, thanks for reporting back and glad it works for you now. I've just pushed an update to NUT where the "preview (latest build)" backend is now today's master including the fixes for your driver. So after updating NUT you just need to choose the "preview (latest build)" backend in NUT Settings and reboot your system afterwards, then you'll be on that driver natively (also surviving any system reboots). Thanks again for your help and patience investigating this issue. 🙂

It would be great if the Samba Worm VFS module could be configurable on a per-share basis through the Web GUI (as on TrueNAS). It's extremely simple to integrate into an individual share configuration and would help harden Samba shares against ransomware from Windows clients a bit, something I'm sure many users here would appreciate. It's really just an additional Samba layer that can be activated and deactivated without trace at any time, so it works cleanly and without messing with the Linux file permissions or actual files underneath. Most of the ransomware originates from Windows clients. What the Worm VFS module does (when activated) is allowing to put new files onto a read/write Samba share, but disallowing writes to those files after a certain amount of time has passed (the grace period). So you could set up a grace period of 24 hours, where you can still make changes to any new files from these last 24 hours and once that time has passed they're turned read-only on that Samba share. This could be very useful for media libraries, as an example, where later changes to the files by the user are not to be expected. It's just two lines in the share configuration: vfs objects = worm worm:grace_period = 86400 # 1 day https://wiki.samba.org/index.php/Using_the_worm_VFS_Module

Sorry, it doesn't seem like this UPS manufacturer is supported by NUT at all. It's also not listed in the hardware compatibility list: https://networkupstools.org/stable-hcl.html

I'm just happy there's multiple solutions for multiple use cases (and user groups), a lid for every pot. 🙂

nut-2.8.2-x86_64-2debug.txz Here we go - current master with debug symbols, same procedure as before. Please do report back again with your findings - thanks in advance! 🙂

Thanks for the detailed write-up, I'll build a new debug package as soon as possible (most likely tonight). 🙂

There's three priorities in the GUI: Green - nothing out of the ordinary is happening (OL, CHRG, CAL) Orange - something out of the ordinary is happening (OB, BYPASS, DISCHRG, TRIM, BOOST) Red - something critical is happening (LB, HB, RB, OVER, OFF, FSD) So orange is not necessarily bad, it's just that the UPS is doing something for the user to notice in the GUI.

The last active topic seems too cramped in comparison to the huge part with the forum name (having lots of unused white-space). Removing the width: 100% on .ipsDataItem_main it'd look like this (better in my opinion): I know it's a work in progress and I love the new forum software, but I'm not too happy about some changes myself. I think the light mode is too bold (better lower font-weight?) and bright (better light gray instead of full white?), while some layout (example see above), font and color choices still look a bit hacked together rather than feeling "native" yet (in lack for a better word). Perhaps a better choice would have been to keep the fonts and color palettes that people were used to, while upgrading mostly the forum software and the layout around it. Nonetheless thankful for all the (ongoing) hard work put into improving the website and community. 🙂

Light Mode does not seem to work at the moment - otherwise looking good!

You need to stop NUT, change the setting and then start NUT again - it cannot be changed when it's running.

pollonly Just put this in UPS.CONF on line 8 using GUI configuration editor and restart NUT afterwards. But if all works as it should, I'd just ignore these messages in syslog and not mess around with extra settings.

I have no information about multi array support or how it will be implemented, sorry about that. mergerFS basically can pool multiple disk mount-points together, so regardless where the data is residing physically it can then be accessed through one single folder (the mergerFS mount-point). Some users use this functionality to pool data on the array and data residing in the cloud together (e.g. for Plex), others use it to pool multiple disks mounted through Unassigned Devices together for better accessing through a single custom share/location on the server. I'm not sure how well it would perform pooling already pooled data (if I understood you correctly there, since array pools and cache pools already are pooled you'd be pooling pooled data) and if or how that would interfere with Unraid. Regarding SnapRAID, that's not really got anything to do with mergerFS. Basically SnapRAID provides parity for multiple individual disks (mounted in their individual disk mount-points), but doesn't pool array data by default (as Unraid does with the user shares). So mergerFS could be used to pool a SnapRAID array (consisting of a bunch of individual disk mount-points) into one folder (the mergerFS mount-point) for e.g. later sharing through a custom SMB/NFS share. Hope that makes sense a bit. 🙂

LLDP broadcasts on all eth* (so eth0, eth1, eth2 ...) interfaces, so both on eth0 and eth1 in your case. It seems to be advertising as the management IPs both the IPv6 IP of your eth0 interface (as you have IPv6 enabled there) and the IPv4 IP of your eth1 interface (as you have IPv6 disabled there). I think that it's doing what it should, considering you have two physical interfaces (eth0, eth1) and it's advertising both with the respective default IP of each respective interface. Would you have liked for it to advertise the IPv4 IP of eth0 (even if you're using IPv6)? I can try to add a setting to manually override the advertised management IPs, but I'll have to look how to implement that so might take a while.

SnapRAID on UNRAID A plugin for advanced users installing SnapRAID onto UNRAID systems. Possible Use-Cases: Parity protection and a degree of corruption detection/repair for custom-mounted (e.g. using UD), possibly mergerFS-fused/pooled, unassigned disks outside of the primary Unraid array - either due to not always being online (cold backups) or exceeding the maximum possible array size of 30 disks, as commonly seen with large mixed disk JBOD/DAS solutions not wanting or being able to go full ZFS (primary use-case). A degree of corruption detection/repair for rarely changing large file libraries (e.g. on media or backup servers) in conjunction with Unraid parity, sacrificing an Unraid array data disk for SnapRAID parity to leverage the advantages of both Unraid and SnapRAID (experimental use-case). You tell me - post here if you have another exciting use case that worked well for your specific storage needs. General Usage Warning: As with any software interacting with your data, only ever use it on backed up data and in combination with a solid backup strategy. Read the manual and help-texts before acting and if you do not understand a 100% what you are doing, please just do not do it... 🙂 This thread is not really for teaching how to use SnapRAID. It is primarily intended for reporting and solving problems around the plugin itself. If the detailed SnapRAID manual and amply provided hover/F1 help-texts are not enough to bring clarity on using the software, this plugin will most likely have no real benefit for you (no offense). It was made for advanced users with very specific storage needs, not to just play around with without purpose (if you value your data). Installable via Community Applications