Boyturtle

I asked a question about logrotate and someone commented "this thread is user using logrotate incorrectly and not reading nextcloud docs", but no advice towards a fix nor where to look. Not helpful at all.

My server shutdown today without warning. It was not a graceful shutdown as it started a parity check immediately after restart. When I restarted the server it did not boot into unraid, but got stuck in the bios, I had to force it to choose the unraid flash drive to boot up correctly. I've set my unraid to be a syslog server, and looking at unraids own logs, the last entry before the restart (19:52) was at 04:10 today. Looking at the logs from other devices, I see that the last entry from them to the syslog server was at 14:16, so I guess it went down at about that time. We've not had any power outages here today and my server is on a UPS (the NUT server plugin is outdated and needs an upgrade, but this should not have caused the problem). We've had no electrical storms here today and nothing else in my home is affected. It may be that the flash drive (which is USB 3) is not happy, although it is just over a year old. I have found a Transcend JetFlash 600 USB 2 drive with MLC nand that I plan to migrate the OS to in due course. I've attached diagnostics and would appreciate any suggestions about what may have caused my server to shutdown nabu-diagnostics-20240117-2102.zip

I've had this docker up and running for a while now and I'm surprised how variable my connection speeds are and I'd like to raise this with my service provider. To support this, I'd like to be able to export the data to a .csv and I note in the github documentation that this is available. Can someone give me a step by step guide to set this up? I have the basic install (sqlite)

Ok, I'll just add it to the array then :-)

I completely missed this. I found the box and checked it and now it is all working, thanks. I will preclear the old parity 1 before adding it to the array. Thanks again for your assistance.

Using the process you mention above, I am unable to start the array after unassigning parity 1; the button option is greyed out and the disk is labelled as missing. My only option is to reboot the server and when I do, parity 1 is back again.

I have tried to upgrade my parity to a larger drive (12TB) and then add the old parity (8TB) to the array, but it is not working for me following the suggestions in this post. After preclearing the new drive and stopping the array, I added the new drive as Parity 2, brought the array back up and let the parity sync. I was able to disable VMs and Docker while I did this and the sync process took approximately 24 hours. I then stopped the array and tried to change the old parity drive (P1) to "no device" so that it would become unassigned, and I could preclear it, ready to add to the array, but it would not accept this after the restart and the old parity resumed as P1. I tried to remove P1 to "no device" and then adding it to the array, but after reboot, the old parity resumes as P1 again. I'm not sure if this is relevant, but when I unassign the old parity drive, it is listed in the Unassigned Devices as Dev 1, but there is already another Dev 1 device in that set of disks. I'm not sure what I'm missing here and I've attached my diagnostics. Thanks nabu-diagnostics-20230511-1421.zip

Thanks for this, it now works perfectly, as before. I have no idea how this setting changed!

I have a WD Purple drive that a remote PC writes to 24/7; it is in unassigned devices and has been set to share. I recently upgraded the Unraid hardware (CPU, mobo, RAM and the Unraid flash disk as it was showing signs of failure at about the same time) and since then (I think), it hasn't shown up on the available server shares on the network; so I'm unable to map to it from Windows clients nor mount it from other Linux devices. The drive mounts ok within Unraid and I'm able to read the contents. I have a workaround by creating a folder share that simlinks to the purple drive, but I'd rather have it working properly. I've attached the diagnostics and would appreciate any suggestions to fix this. Thanks nabu-diagnostics-20230301-1314.zip

I'm looking at upgrading my Unraid server to allow me an amount of future proofing, taking into account future VMs (including a Mac, up to 3 Windows and pfSense), the ability to hardware transcode for Plex and to run a number of dockers. My current setup, that has been running for about 5 years now, is a Xeon 1230v5, 48GB ECC RAM, 3 cache drives, 4 storage drives and a parity all nestled in a Define R6 on a Supermicro X11SSM-F-O Motherboard with a Corsair RM750X 80+ Gold PSU. When I have all my dockers and 1 windows VM running at the moment, the CPU can get pegged at 80-90% and things have a tendency to slow down considerably when this happens. I like having IPMI and running ECC RAM and would like to carry this forward to my next build. Having 2 NICs for aggregation is also preferable. I'd like to improve performance without upping my power consumption if possible. I'm considering getting a W680 motherboard from Supermicro (X13SAE-F), 32GB (for now) DDR5 ECC RAM and an i7 12700, I plan to keep the rest of the equipment as is. I've been holding off doing this for a while as I've not been able to get my hands on DDR5 ECC RAM until now; Kingston have recently announced that they have 16GB and 32GB variants that will work with this motherboard. I've also considered similar mobo offerings from Asrock Rack, Asrock Ind and Gigabyte, and these products use DDR4 RAM, but I have not been able to source any products from resellers in the UK, the Supermicro is available, albeit with a 4 week lead time. I'd appreciate any feedback about my choices and particularly if anyone has used a similar set up.

Thanks very much for the insight, this worked for me too. If only I'd found this thread and your post earlier, my partner would not be so upset with me for losing half a day trying to find a fix!

Schoolboy error. I had my firewall rules in the wrong order on pfSense; the open port rule was below on the list and it ran after the block VLAN rule. Moving it above the block VLAN rule resolved the issue I was having.

I can't get Direct Play to work across VLANs, on the server dashboard I have a little exclamation mark and the play is listed as indirect. The Plex server resides on the 192.168.52.0/24 subnet and the the clients that I would like to access the service are on 10.16.50.0/24 VLAN, both are on the same LAN. I have port 32400 open on my pfSense router and am able to transcode the films to the clients, but not Direct Play. If I put the same client on the same subnet as the the server, it Direct Plays. I have this problem if I'm playing 720, 1080 or 4k content. In Settings>Network>LAN Networks I have added 192.168.52.0/24,10.16.50.0/24. I have no subtitles set that I can see in Settings>Languages (I have enabled and disabled Automatically select audio and subtitle tracks, to no avail and have Subtitle mode set to Manually selected). For good measure, I have also added the 2 subnets to the List of IP addresses and networks that are allowed without auth area too, but this did not make any difference so have now removed it. Have I overlooked a setting somewhere?

No errors in the syslogs from 4.40 am and beyond yesterday, after I made the changes described above 😃

Would this stop the daemon from starting at 4.40 every Sunday?

My only weekly scripts are the cleaning up of plex cached files and ClamAV scan, nothing apcupsd related. Installed Dynamix Schedules, user.script.start.weekly.sh runs at 4.30 on Sunday and exportrotate, logrotate, user.script.start.daily.sh run daily at 4.40. My output from cat /etc/logrotate.d/apcupsd is the same as @SimonF /var/log/apcupsd.events { rotate 4 weekly notifempty missingok postrotate /etc/rc.d/rc.apcupsd restart 1>/dev/null || true endscript } As I'm not using unraid's apcupsd, am I safe to edit /etc/logrotate.d/apcupsd and comment out the line /etc/rc.d/rc.apcupsd restart 1>/dev/null || true? Should this stop the daemon restarting?

Thanks for your reply and apologies for not replying sooner nor making my earlier post clearer. My preference is to run the UPS management on a device that sips power (hence the Pi) and my unraid server is much more power hungry. Doing it this way allows me to shut unraid down before other devices on my network. What I'd like to achieve here is to disable the apcupsd 3.14.14 (31 May 2016) slackware startup, but have no idea how to to stop this. Effectively, I'd like the deamon to revert to how it was before I made the initial changes when adding the UPS. As I stated in my earlier post, there is nothing in cron to indicate that there is anything in place to start at 4:40 every Sunday morning. Do I need to make changes in unraids /etc/apcupsd/apcupsd.conf file, /etc/rc.d/rc.apcupsd or an altogether different file?

I was using the built in UPS settings in Unraid, but this was not sufficient for my needs as it didn't support other item on my network, so I installed NUT server on a Raspberry Pi, connected the UPS USB cable to it, added the NUT docker to Unraid and connected it all up to the Pi NUT server while switching the UPS Settings> Start APC UPS daemon to No. Everything seems to be working with the NUT server, all my devices see it and are set up accordingly, including Unraid. Unfortunately, every week on a Sunday at approx 04:40 I get a notification apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Communications with UPS lost these errors continue to be logged until I manually switch off the daemon Settings>UPS Settings. When I go to the Settings>UPS Settings tab, the status is showing as running, despite the Start APC UPS daemon showing as no. The way to switch this off is to click the default button which resets it. FWIW, I have ran cat /etc/cron.d/root and nothing is listed as running around 4am on a weekly basis. Has anyone else experienced this or can anyone give me an idea on how to apply a correct fix other than setting a cron job a few minutes after the daemon starts to switch it off?

Did you ever get to the bottom of this? I have exactly the same issue, even down to the time of 4.41 a.m every Sunday!

Did you get this to work? If so, can you share please?

I was running the unraid UPS daemon for some time, but due to adding more devices that needed UPS support, I decided to move to a NUT server running on a Raspberry Pi. Moving the Unraid server and adding all the other devices to the NUT server went smoothly and everything seemed to be working well, until after 1 week when I got an error that Unraid had lost connection with the UPS daemon. At first, I thought it was a one off, but then it started to happen every week and usually at the same time (04:41) and I'm now concerned that something more serious might be causing this. FWIW, the settings are --- Start APC UPS daemon: No UPS cable: USB Custom UPS cable: Blank UPS type: USB Device: Blank Battery level to initiate shutdown (%): 10 Runtime left to initiate shutdown (minutes): 10 Time on battery before shutdown (seconds): 0 Turn off UPS after shutdown: No Looking at the logs, I've got this entry just before the warning notification: apcupsd[29559]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded apcupsd[29559]: NIS server startup succeeded apcupsd[29559]: Communications with UPS lost. It seems that on other instances on the logs where "apcupsd[29559]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded" is logged but doesn't cause any problems, there is a further 2 entries "apcupsd[29559]: apcupsd exiting, signal 15" and "apcupsd[29559]: apcupsd shutdown succeeded". I have no idea why this command sometimes triggers and not others. The workaround is easy, I just click the default button and everything goes back to normal, until the following week, I would prefer that it didn't do this, but I've no idea where to start looking, can someone please give me an idea where to look?

Can you point me to the script please?

I've just had a 'Doh' moment. I'd got another share that I should've set to use this pool, but hadn't enabled it. I've fixed that now and it seems to be moving files across now.

My original pool works just fine, but a few months ago I added another pool dedicated for my download share. When Mover is invoked manually or via the schedule, only the original pool data is moved across. I'm not running the Mover tuning tool. Cache is set to Yes in the share. There is plenty of space in the destination. I have enabled mover logging and looking at syslogs and invoked the process manually; it appears that data is only moving from the original pool and the second pool (Download_cache) isn't even coming up on the logs. I've attached my diagnostics speedy-diagnostics-20210915-1459.zip

This seems to be working for me too. Cheers