asked on

Snap Server Will not mount Volume

Recently called in to work on new customers snap server 4200. The server is in a raid 5 configuration and has only one volume. The server will not mount the volume. Customer does not know what happened just stopped working 3 weeks ago. I suspected power outage. After going through step by step from snap support of :

When the Snap Server with a GuardianOS version running on it abruptly shuts down due to a loss of power, this is called an "ungraceful shutdown". The web interface shows the recovery console and users are unable to access the files and folders on the Snap Server shares.

The first thing to check here is to have customer go to the following site on the Snap Server:

"http://"Snap Server Name" or "Snap Server IP Address"/debug.html

This will get the customer to the Debug Console window. From there, enter "df -h" in the "Command" field and press "OK" button to execute. Check the root file system.

At this point, ask customer if they have backed up their data from this Snap Server recently. Advise them that the next few steps may affect the data on this server, if not outright lose it. Also ask customer if they have Putty.exe installed on their workstation. If not they will need it for the tasks outlined below. If they choose to proceed with the repair attempt, then perform the following steps:

1.) Enter "cat /etc/fstab" in the "Command" field and press "OK" to execute. Verify that the fstab file is complete.
2.) Enter "cp /etc/fstab /etc/fstab.bak" in the "Command" field and execute it. This will copy the fstab file over to fstab.bak in the /etc directory.
3.) Enter "rm /etc/fstab" in the "Command" field and execute it. This will delete the fstab file from the Snap Server--remember, there is another one saved in fstab.bak for later use in these tasks.
3.) Reboot the Snap Server.
4.) After the reboot, see if the Home page of the Server can be accessed and enable SSH.
5.) Have customer run Putty.exe from their workstation and try to access the Snap Server through a SSH session. This will access the Linux part of the GuardianOS.
6.) Have customer log in as "admin" on the SSH session and then su over to "root user" on the SSH session. This will be indicated by a hashmark ("#") for the prompt.
7.) Enter "xfs_repair /dev/volgr(v)/lvol(n)"--where (v) is the number of the problem volume group and (n) is the number of the problem logical volume--at the prompt and execute. This command will go through 7 phases until it is complete.
8.) Have customer the enter "cp /etc/fstab.bak /etc/fstab" and execute it. This will put the fstab file back in its original place.
9.) Close Putty.exe.
10.) Reboot the Snap Server from the Web Interface.
11.) Check and see if the volume is mounted after the reboot and see if customer can access data.

The volume continues to not mount?

Duncan Roe

What was the output from the xfs_repair session?

ambientsbs

ASKER

sh-2.04$ xfs_repair /dev/volgr0/lvol0
/dev/Qhwif: Permission denied
Qhwif_fd not set up
xfs_repair: warning - cannot set blocksize on block device /dev/volgr0/lvol0: Permission denied
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- 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
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- agno = 32
- agno = 33
- agno = 34
- agno = 35
- agno = 36
- agno = 37
- agno = 38
- agno = 39
- agno = 40
- agno = 41
- agno = 42
- agno = 43
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- clearing existing "lost+found" inode
- deleting existing "lost+found" entry
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- agno = 32
- agno = 33
- agno = 34
- agno = 35
- agno = 36
- agno = 37
- agno = 38
- agno = 39
- agno = 40
- agno = 41
- agno = 42
- agno = 43
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- ensuring existence of lost+found directory
- traversing filesystem starting at / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

Duncan Roe

It appears xfs_repair was not run as root. It needs to be

ambientsbs

ASKER

Fixed that and ran as root still same issue. No repairs or anything new on the report looks as it did above.

ASKER CERTIFIED SOLUTION

Duncan Roe

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ambientsbs

ASKER

Sorry, my client chose to go in a different direction here rather than having me continue down the "troubleshooting" path. I accepted your answer as a solution although I can't say that we actually solved the problem.