mcham27

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by mcham27

  1. In case someone else runs into it, the noip.conf generated template from first-run (for me at least) ended up generating a misleading set of instructions. Above the interval line, the examples had a space between the value and the unit of measurement. At the time, there wasn't an explicit version number available, but as of Dec-13-2019, the Docker definition was last updated "A Year Ago." # Examples: 5 m, 5 h, 5 d. Minimum is 5 minutes. INTERVAL='2 h' Including said space results in the container refusing to remain running, with the following being logged. INTERVAL must be a number followed by m, h, or d. Example: 5m run-parts: /etc/run_once/parse_config_file: exit status 2 Run-once scripts failed. Stopping container Shutting down container... fail: noip: runsv not running sh: you need to specify whom to kill Removing the space (between the value and the unit of measure) from the interval resolved my issue, and updates claim to be trying to happen for me. It looks like I still will need to click on the email link every few weeks to prevent the host from expiring, but that's from me being cheap and using the free tier of no-ip. # Examples: 5 m, 5 h, 5 d. Minimum is 5 minutes. INTERVAL='2h'
  2. Your understanding was correct, and thanks for response. I'd rather re-write the first 19.8% than trust the blocks from roughly when the controller did its reset, during reads. As long as cancelling does not lull the system into a false sense of security- I'm OK with it starting over.
  3. Yesterday I started rebuilding a 4TB drive (2.85TB/4TB utilitized). The initial estimate was 141MB/s, and 20-some minutes in it was down to 120MB/s, which still would've completed this morning. When I checked on it at roughly 12:45am, 3-4 hours later, the speed had dropped to under 70KB/s. Rather than chasing it then, I just let it do its thing over night. The sub-12 hour projections have now turned into just over 1.5 years. The "Cancel" is clearly labeled has leaving the array unprotected- . However, with it using the "same cable" SAS=>SATA breakout cable on the same SUPERMICRO AOC-SAS2LP-MV8, after unraid disabled the previous 4TB drive in that spot in the array (for a series of block-level write errors) it could've been a cabling item or a controller issue (went into service late Aug-2014). But, from this state during a rebuild... is there a way that would permit me to restart the rebuild from parity again? Circumstance: I simply pulled the old drive, which is already 10 days "out of the array" (hadn't reconfigured notifications) so I'd definitely want to rebuild the drive rather than blessing it, and generating a new parity. The "replacement" drive had arrived yesterday morning, and with the array having been in an emulating state for over a week... I did not preclear it, restoring the protection for the rest of the array, prior to message with the "disabled" device outside of the system was my intention... Based on the attached dmesg, the drive that 'encountered' the command error was one of the "old" 2TB green drives that has been in use since I was running 4.6. However, the other 3 drives on the SAS2LP-MV8 include the 4TB parity [which probably should be on a motherboard header...], 3TB data, 4TB being rebuilt. unraid_6-1-9_syslog.txt unraid_6-1-9_dmesg-grepping-ata1.txt
  4. Really don't have anything insightful, except that it is happening for me on 6b12 as well, but with reiserfs (opposed to XFS) on the disks. Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27617): mkdir "/mnt/user/iTunes" Dec 10 18:11:05 unraid6b12 emhttp: shcmd: shcmd (27617): exit status: 1 Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27618): rm "/boot/config/shares/iTunes.cfg" Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27619): :>/etc/samba/smb-shares.conf Dec 10 18:11:05 unraid6b12 avahi-daemon[5185]: Files changed, reloading. Dec 10 18:11:05 unraid6b12 emhttp: Restart SMB... Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27620): killall -HUP smbd Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27621): cp /etc/avahi/services/smb.service- /etc/avahi/services/smb.service Dec 10 18:11:05 unraid6b12 avahi-daemon[5185]: Files changed, reloading. Dec 10 18:11:05 unraid6b12 avahi-daemon[5185]: Service group file /services/smb.service changed, reloading. Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27622): pidof rpc.mountd &> /dev/null Dec 10 18:11:05 unraid6b12 emhttp: shcmd (27623): /etc/rc.d/rc.atalk status Dec 10 18:11:06 unraid6b12 avahi-daemon[5185]: Service "unraid6b12" (/services/smb.service) successfully established. Based on how my 'current' 5rc8 handles it, which really isn't relevant in the big scheme of things, every folder (all 35 on the disk I specified) did get turned into a share after not configs were found after mounting /mnt/user, writing to /etc/samba/smb-shares.conf (in memory). However, as shown in my code/log snippet above, my attempt (unregistered USB stick) also had an exit status of 1 on the attempt to create the /mnt/user/iTunes directory, and then it went to remove the non-existent iTunes.cfg within the (empty) "flash"/config/shares folder of the server. As to the underlying cause of the "exit status: 1" from shcmd, I'm not sure. However, I am using "flash"/config/smb-extra.cfg for mounting a multi-partition disk outside of the array (toying with ext4, btrfs, xfs on one physical drive). "flash"/config/share.cfg from my unraid6b12 instance, and based on the 5rc8 behavior shareUser="e" is enabled, while shareUser="-" is disabled. # Generated settings: shareUser="e" shareUserInclude="" shareUserExclude="" shareSMBEnabled="yes" shareNFSEnabled="no" shareNFSFsid="100" shareAFPEnabled="no" shareInitialOwner="Administrator" shareInitialGroup="Domain Users" shareCacheEnabled="yes" shareCacheFloor="2000000" shareMoverSchedule="40 3 * * *" shareMoverLogging="yes" fuse_remember="330" shareAvahiEnabled="yes" shareAvahiSMBName="%h" shareAvahiSMBModel="Xserve" shareAvahiAFPName="%h-AFP" shareAvahiAFPModel="Xserve"