Suddenly the main RAID CIFS share stopped working. It seems for some reason nobody could mount this share anymore. All user got an access denied on mount attempts.
So what the hell was going on: The rather simple web interface wasn’t the burner, in fact the system log does not deserve the name Log 🙂
So mostly every RAID in this class is based on an embedded system driven by our friend Linux. This one is no exception.
So we first need the most important part,…. a working telnet or SSH connection. But a first “test” connection to the SS4400 device gave us “connection refused” as expected.
Luckily after some googling I found a hind that on this devices you can enable the SSH interface via a hidden CGI script.
Now you can login via “root” and your administration password.
By the way, this device comes with the Swiss Army Knife of Embedded Linux BUSYBOX which I also use for my embedded projects. I’m working with Busybox sense 2004 (version 0.94x), ….. great stuff :-).
But it seems, INTEL has some GPL violation with these devices. lol, ..On our bundled CDs we didn’t get any GPL sources from Busybox and Co? This is only mentioned in passing.
In our case a look into the system logs indicates that our RAID share had some file system problems. INTEL uses XFS as the file system on the storage device. Our system log was filled up with error messages of the file access layer.
In our case the solution was really simple. On device startup the file-system reports that there are errors, but then the corrupt partition is mounted and then ,… kabudl……
To fix this you first have to detach the corresponding RAID with “NASdetach”. Now you can unmount the partition and run the XFS repair binary “xfs_repair“.
After 10 – 15 min the repair should be finished.
Reboot the storage device and you should be able to access your share.