Hello All,

  I am new to this sort of stuff. I have been running unRAID a while now though, with minimal issues.

 

Starting a few nights ago, I can no longer access my server via WebUI, and browsing to it, I can not see the shares, only the FLASH drive. I can ping it, and I can SSH to it.

 

This is a new issue, there have been no changes to the configuration, anyone have any recommendation?

 

Again, I am pretty new to anything linux/ssh, so bear with me!

Was this since upgrading to 6.3.5?

No. I upgraded a month or so ago (I apologize, I don't recall what version), and its ran fine since then. This problem literally started out of no where. No changed were made, it just stopped responding one day.

As i mentioned, I am able to SSH into it. I attempted to reboot through that. I get the message it's rebooting, but never does.

I've hard powered it off, I've even tried changing the USB port. Hooking a monitor up to the server as well. It boots, and shows no errors, and allows me to log in there as well. I just can't access and server shares or the webUI.

Are you trying to access via hostname or IP?

Neither way will work. 

I also have a mapped drive to my work PC, and all my media shares are not present, just the Flash drive.

I know the server itself isn't running, as I can not access Sonarr or Plex either. (may have been something to lead with)

39 minutes ago, Brentum84 said:

I can SSH to it.

We need to see diagnostics before reboot. Type

diagnostics

at the command line. It should save your diagnostics to flash, then post the complete diagnostics zip.

Here is the Zip

 

daltonserver-diagnostics-20170606-0905.zip

Your syslog is full of hack attempts. Why have you put your server on the internet? Close your router ports.

I've closed the ports. It's always been forwarded for Plex to be accessible remotely. 

Any other things I can do besides re-flash the boot USB?

 

 

After doing what trurl said you need to fix filesystem on disk1, disable array auto-start by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no".

 

Then start the array in maintenance mode and check filesystem on disk1 (md1):

 

https://wiki.lime-technology.com/Check_Disk_Filesystems#Drives_formatted_with_XFS

27 minutes ago, johnnie.black said:

After doing what trurl said you need to fix filesystem on disk1, disable array auto-start by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no".

 

Then start the array in maintenance mode and check filesystem on disk1 (md1):

 

https://wiki.lime-technology.com/Check_Disk_Filesystems#Drives_formatted_with_XFS

Is there a way to start Maintenance mode through SSH? I still cannot access the Webgui.

 

I have closed the ports, rebooted the server and re-ran diagnostics. Using this, I verified there is no more failed attempts to log in.

32 minutes ago, johnnie.black said:

disable array auto-start by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no".

 

If you do this you'll be able to access the server using the webGUI where you can start the array in maintenance mode.

Just now, johnnie.black said:

 

If you do this you'll be able to access the server using the webGUI where you can start the array in maintenance mode.

 

 

Thank you. I did this once, but it changed it back on reboot. I was able to get it going this time around.

 

I am running the xfs_repair on md1 right now. I will report back what the results are.

 

Thank you both for your help and being patient with my noob butt

I am unable to mount the drives.

What risk do I run doing the xfs_repair -L option?

"root@DaltonServer:~# xfs_repair -v /dev/md1                                     Phase 1 - find and verify superblock...
        - block cache size set to 2278136 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 579420 tail block 497759
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
root@DaltonServer:~#"
 

Just now, Brentum84 said:

I am unable to mount the drives.

What risk do I run doing the xfs_repair -L option?

"root@DaltonServer:~# xfs_repair -v /dev/md1                                     Phase 1 - find and verify superblock...
        - block cache size set to 2278136 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 579420 tail block 497759
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
root@DaltonServer:~#"
 

Let me rephrase... What is the probability of losing data? Or is there even another alternative at this point.

use -L, it's normal in these situations and usually there's no data loss.

Thanks, Currently running.
would you like to see the log after this? Shall I attempt to remount?

After it finishes start the array normally, then look for a lost+found folder on that disk, any corrupt/incomplete files should end up there, if it's empty all should be OK.

1 minute ago, johnnie.black said:

After it finishes start the array normally, then look for a lost+found folder on that disk, any corrupt/incomplete files should end up there, if it's empty all should be OK.

 

There's two files. But there is no size ro them, they are just a numbered file.

Array started perfectly! all my shares are back! and from what I can tell at a glance, I lost nothing!

 

You guys rock! Thank you for helping me fix this, and learn as I did it!