Dieseldes

Members
  • Posts

    68
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

Dieseldes's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. For me my ups is in a different room/ building, so networking was the only option.
  2. Thanks very much for the feedback.. A server reboot got it running 100%! Now i just need to do a power fail and see how it actually acts. I have the system running off 250AH worth of external batteries so it could take some time before it needs to actually shut down. Cheers Des
  3. Guys, Sorry for bring this thread back up but im struggling getting Unraid to talk to my APC 1500 2u rack UPS over ethernet. I can talk to the UPS via its webpage at 192.168.1.60 and i can pig the device etc, but the UPS settings page in Unraid seems to refuse to see the UPS. I also dont seem to see any errors in the UPS log that i would expect if a password was wrong, so im not sure if Unraid is even trying to talk to the UPS. I had setup the passphrase as "admin-user-phrase" within the ups and then have this under device in unraid "192.168.1.60:apc:admin-user-phrase". Its setup as Ether and have tried pcnet and SNMP. What am i missing? Thanks des.
  4. Pm sent Sent from my Moto G (5) using Tapatalk
  5. Thanks for the advice. I now have a fully operational system again[emoji6] Sent from my Moto G (5) using Tapatalk
  6. Thanks guys! So am I best deleting the docker and then installing again? Should I delete any particular files? Are there any idiot proof guide to installing this from scratch? Cheers! Sent from my Moto G (5) using Tapatalk
  7. Sorry to be a pain guys but in getting nowhere with this on my own. Can anyone point me in the right direction? Should I remove the docker and try again or any suggestions? Thanks! Sent from my Moto G (5) using Tapatalk
  8. Can anyone assist me with this issue? If this isn't the right forum can you point me in the right direction? Almost all my downloads now fail making this system useless for me. Thanks in advance, des. Sent from my Moto G (5) using Tapatalk
  9. Hi all. I upgraded from "needo" version to the linuxserverio version as it seems to have better support. Anyhow since upgrading i have has issues which i believe are related to permissions. When a tv show downloads i get a fault "2018-02-24 19:54:41,568::ERROR::[misc:1597] Cannot change permissions of /config/Downloads/complete/tv/xxxxxxxx" Where xxx is the tv show. I have checked the SAB config and have played with the permissions value, but its at 777. It seems SAB cant change the file and so post processing fails. Im totally lost, so can anyone help me resolve this issue? Im not sure if this is a sab issue, an unraid issue or what? Thanks des.
  10. Parity check completed finding zero errors so looks like I'm all good. Thanks des.
  11. OK thanks for the feedback. I have no idea how the zip file got split out into the individual files. Sorry about that. My microserver runs on a 12v psu from a 200 amp battery which powers it for a few days at normal load. The battery is charged when the mains is on (99.98%) of the time so the server never sees a mains failure. I also always shut the server down from the guinea and before the upgrade to 6.3x it had been up for 180 ish days. Based on the a over any other thoughts as to why the corruption would of happened? I will run a parity check now just to be sure how things are.
  12. Should I be OK to do a parity check after this event? Thanks in advance des.
  13. Ok, reran the file system check with -nv and the fault has gone, so suspect the checker "fixed" the problem the first time? Anyhow, i restarted the array in normal mode and now i can copy to the server again on the directory i couldn't before. Anyone know what would of caused this? Should i be concerned?
  14. Here are my diagnostic files.S-----------e.cfg disk.cfg docker.cfg domain.cfg go ident.cfg network.cfg share.cfg smart-one.cfg super.dat docker.txt syslog.txt no qemu log files a-----a.cfg m--------e.cfg S-----------e.cfg HGST_HDN724040ALE640_PK1334PBGTHZNX-20170312-0150.txt SanDisk_Cruzer_Fit_4C532000070728119385-0-0-20170312-0150.txt SanDisk_SDSSDA240G_151987404336-20170312-0150.txt ST8000AS0002-1NA17Z_Z840AS05-20170312-0150.txt ST8000AS0002-1NA17Z_Z840FDHC-20170312-0150.txt WDC_WD60EFRX-68MYMN0_WD-WX31D3408887-20170312-0150.txt cmdline.txt df.txt ethtool.txt folders.txt ifconfig.txt iommu_groups.txt lsmod.txt lsof.txt lspci.txt lsscsi.txt lsusb.txt memory.txt ps.txt vars.txt unRAID-6.3.2.txt
  15. So everything was great in my Unraid world until a few days ago i upgraded from version 6.1X to 6.32. Everything seemed OK, but since then i noticed my backup software on my mobile phone complaining that it couldnt write to the unraid server sometimes. I have just had a chance to have a look and sure enough my pc on the same LAN network cant write to some folders. So i restarted unraid which made no difference. Then I put unraid in maintenance mode and ran the file system checker on my drives which are all XFS. All looked ok to me on all but 1 drive, and it showed a diffrent result to the rest. So i tried running the command with just the -v switch from the GUI and this is the result. Not available Phase 1 - find and verify superblock... - block cache size set to 251280 entries Phase 2 - using internal log - zero log... zero_log: head block 12582 tail block 12582 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:71270) is ahead of log (1:12582). Format log to cycle 4. So that last bit looks wrong to my untrained eye. What should i do now?? Cheers Des