Jump to content

TheWombat

Members
  • Content Count

    182
  • Joined

  • Last visited

Community Reputation

2 Neutral

About TheWombat

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Upgraded to 6.7.2. Server seemed unstable and was shutting down and then going into reboot loops, but appears to be the CPU water cooler finally giving up rather than anything specific to 6.7.2. Have fitted new CPU cooler and will report back if any issues remain, but so far looking promising. Asus M5A99FX Pro R2.0 with BIOS 2501. AMD FX-8350 CPU. 16GB RAM.
  2. When I login locally on my unraid server gui the resolution seems to be something like 800x600 so it is almost unusable. Is there a configuration setting to change the resolution to something higher? thanks TheWombat
  3. Read the instructions and notes and ensured unsupported plugins removed. Upgraded from 6.3.5 to 6.4.1 with no issues. My setup is simple - just a docker container. No VMs etc. Have not taken the encryption/certificate route yet. thanks
  4. You may need to remove any other cards from the machine. For example I have an Intel network card in my machine, plus 2 SASLP cards and found that I had to remove the network card and one of the SASLP cards in order to boot into the bios. Alternatively if you have another PC e.g. a windows desktop you can temporarily put the SASLP into that and do the flash update since you use a separate boot OS. hth TheWombat
  5. I just uploaded .21 and .15n to this post AOC-SASLP-MV8 firmware.zip
  6. Unfortunately not. Would still like to find a solution that works....
  7. Just in case anyone else encounters the same type of issue I can happily say the issue is now solved. After several months of getting the daily email with the error I did some further research which resulted in an edit to my S20-init.rsyncd file to include the line: "chmod 644 /etc/logrotate.d/rsyncdlog". the file contents now are: #!/bin/bash if ! grep ^rsync /etc/inetd.conf > /dev/null ; then cat <<-EOF >> /etc/inetd.conf rsync stream tcp nowait root /usr/sbin/tcpd /usr/bin/rsync --daemon EOF read PID < /var/run/inetd.pid kill -1 ${PID} fi cp /boot/custom/etc/rsyncd.conf /etc/rsyncd.conf cp /boot/custom/etc/logrotate.d/rsyncdlog /etc/logrotate.d/rsyncdlog chmod 644 /etc/logrotate.d/rsyncdlog
  8. Is anyone else noticing that unassigned HDDs do not seem to spin down correctly? I posted the issue on 6.3.1 which is when I first noticed it. The issue didn't appear on 6.2.4 and I skipped the 6.3.0 release. When i click on the spin down arrow beside an unassigned HDD on the 'Main' tab of the GUI it appears to spin down, and the syslog shows "emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdr" However when I then click on the 'Dashboard' tab, and then back on the 'Main' tab the HDDs once again show the 'spin down' icon i.e. they have not spun down.
  9. I am noticing a few items/issues since upgrading from 6.2.4 to 6.3.1. Diagnostics attached. Items are. 1) Feb 12 18:42:57 NAS-03 root: Warning: file_get_contents(): Filename cannot be empty in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php on line 146 2) Feb 12 18:42:58 NAS-03 root: error: webGui/include/ProcessStatus.php: wrong csrf_token Feb 12 18:42:58 NAS-03 root: error: webGui/include/ProcessStatus.php: wrong csrf_token 3) Unassigned devices appear to spin back up. I clicked the spin down buttons for disks sdr/sdq/sdn via the gui. A couple of minutes later I see the disks appears to either have not spun down, or have spun back up so click on spin down again. Feb 12 18:43:30 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdr Feb 12 18:43:32 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdq Feb 12 18:43:34 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdn Feb 12 18:45:32 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdr Feb 12 18:45:35 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdq Feb 12 18:45:38 NAS-03 emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/hd_parm down sdn Items 1) & 3) are repeatable across 3 reboots since running 6.3.1. I have only just noticed 2) however it may have existed on the prior reboots running 6.3.1 as well. Any suggestions/help appreciated. nas-03-diagnostics-20170212-1846.zip
  10. The only time I have come across something similar was with an older motherboard that I had that had limited BIOS memory space available. The fix was to disable the RAID on the SASLP-MV8 cards (which requires tweaking the config file). Are you sure you hadn't previously disabled the RAID functionality on your original cards? When you go into the BIOS of the SASLP cards do they show a RAID option? hth Alex
  11. Unfortunately no one replied. So either no one knows, or no one is using a larger monitor and needs to change the resolution ;-(
  12. I am on v6.2 and since I have 16GB RAM and not much using it other than Plex I've decided to default boot into the new GUI. So far it seems to work fine but is there a setting for changing the resolution since I have a 22" monitor and the default resolution of the GUI seems low? thanks Alex
  13. Hoping someone can help I upgraded from 6.1.9 to 6.2. The upgrade went smoothly however at 4:40:02am every morning I now receive the following email from my UnRaid server. From: Console and webGui login account Subject: cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null Body: error: Ignoring rsyncdlog because of bad file mode - must be 0644 or 0444. My UnRaid server (NAS-03) is setup to receive a daily backup from my Synology server (NAS-02). This was set up a long time ago with help from the LimeTech forum and has not been touched. No errors occurred while on 6.1.x, and this email has only been received since upgrading to 6.2. When upgrading to 6.2. I also did install the Community Applications app. My SysLog has the usual backup entries that start at 1am: Sep 17 01:00:06 NAS-03 rsync[2378]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:00:06 NAS-03 rsync[2383]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:00:07 NAS-03 rsync[2392]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:00:08 NAS-03 rsync[2403]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:00:09 NAS-03 rsync[2414]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:00:10 NAS-03 rsync[2416]: connect from 192.168.1.62 (192.168.1.62) .... Sep 17 01:52:31 NAS-03 rsync[25470]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:52:32 NAS-03 rsync[25476]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:52:33 NAS-03 rsync[25482]: connect from 192.168.1.62 (192.168.1.62) Sep 17 01:52:34 NAS-03 rsync[25488]: connect from 192.168.1.62 (192.168.1.62) Then at 4:40:02 the following Sep 17 04:40:02 NAS-03 root: Community Applications Auto Update Running Sep 17 04:40:02 NAS-03 sSMTP[31080]: Creating SSL connection to host Sep 17 04:40:02 NAS-03 sSMTP[31080]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 Sep 17 04:40:05 NAS-03 sSMTP[31080]: Sent mail for root@gmail.com (221 2.0.0 closing connection d27sm7017493qtd.37 - gsmtp) uid=0 username=root outbytes=514 For my backup configuration on UnRaid I have the following: \\NAS-03\flash\custom\etc\logrotate.d\rsyncdlog # Rotate /var/log/rsyncd.log /var/log/rsyncd.log { missingok daily dateext compress } \\NAS-03\flash\custom\etc\rc.d\S20-init.rsyncd #!/bin/bash if ! grep ^rsync /etc/inetd.conf > /dev/null ; then cat <<-EOF >> /etc/inetd.conf rsync stream tcp nowait root /usr/sbin/tcpd /usr/bin/rsync --daemon EOF read PID < /var/run/inetd.pid kill -1 ${PID} fi cp /boot/custom/etc/rsyncd.conf /etc/rsyncd.conf cp /boot/custom/etc/logrotate.d/rsyncdlog /etc/logrotate.d/rsyncdlog \\NAS-03\flash\custom\etc\rsyncd.conf #The rsyncd.conf file should be placed in the /boot/custom/etc directory. Note that the flash drive it mounted at /boot. So, /boot/custom/etc is really /custom/etc on the flash drive. uid = root gid = root use chroot = no max connections = 100 pid file = /var/run/rsyncd.pid timeout = 600 log file = /var/log/rsyncd.log [dailybackups] path = /mnt/user/BackupDaily comment = Backups read only = FALSE [weeklybackups] path = /mnt/user/BackupWeekly comment = Backups read only = FALSE I'm unclear as to whether I am now seeing the email error as a result of UnRaid 6.2 or Community Applications or both. And whether this error would have occurred in 6.1.x and it was just that I was not receiving emails about it? File boot\custom\etc\logrotate.d\rsyncdlog currently shows as permissions: -rwxrwxrwx root root By way of attempted solutions I have: logged into console and tried to change file permissions of boot\custom\etc\logrotate.d\rsyncdlog to 0644 or 0444 however the permissions do not change irrespective of logging in as root, using su etc. No error message, just nothing changes. Any suggestions on how to resolve? thanks Alex