Share empty after restore

[keith6226]

I replaced/restored a failed drive in my array and everything seems to have come back OK.  The problem that I am having though is that one of my shares appears empty when I try to access it from windows.  All of the settings look OK, and when I navigate through the individual disks (either on my windows machine or on the server), I see the share folder and all the sub-folders and files present, but not when accessing the share directly.  Even when browsing the share folder from the server UI, there are no sub-folders or files present.  I have tried a reboot with no success.

 

Is there a way to move the folders 'back' into the share?

 

This may be unrelated, but an issue that I started experiencing prior to the replacement that continues to persist is that my Docker images disappear each time I reboot.  I can 'reinstall' them, and all my settings and data are there, but having to reinstall them each time is not a workable solution.

 

With thanks for any insight,

 

Keith

 

edit: I am using 6.0b12

[keith6226]

Could really use help on this. From what I have read in the forums if I try moving the files from their current location at //Tower/disk1/HTPC-TV to //Tower/HTPC-TV, all of the data will be lost.  Is a workable solution to move them to a new share? Say //Tower/HTPC-TV2 ?

[Squid]

If the files still exist on the disks, then what I would initially do would be to delete the appropriate share.cfg file on your flash drive.

 

In your case, config/shares/HTPC-TV.cfg

 

Stop and start the array.  The config file will be recreated and you can then go to the shares tab and setup whatever permissions you had on it before.

 

Its also possible that your flash drive could be corrupted somehow.  (This may account for your other problem - not quite sure) - Take the flash drive to a desktop and run chkdsk on it.

[garycase]

Could really use help on this. From what I have read in the forums if I try moving the files from their current location at //Tower/disk1/HTPC-TV to //Tower/HTPC-TV, all of the data will be lost.  Is a workable solution to move them to a new share? Say //Tower/HTPC-TV2 ?

 

You are correct ... if you copy from a component folder of the share [i.e. \\Tower\disk1\HTPC-TV] to the share [\\Tower\HTPC-TV] you will indeed lose all of the data (the files will be zero length).

 

But you CAN copy from either the component folder or the share to a DIFFERENT share.  [e.g. HTPC-TV2]  ... but if you're using a name that close to your original share name be CERTAIN it's different 

 

[keith6226]

A weird thing is happening now -- I can't add shares.  I can access the add shares page, but when I fill it out and submit, the page simply reloads and the share has not been created.

 

I ran chkdsk on the flash drive and found no issues, and I also updated to b14 for good measure, but still no success.  Any idea WTH is going on here?

[garycase]

Are you sure you have shares enabled?

 

[garycase]

... just in case, try toggling the shares setting.  i.e. Disable shares;  then re-enable them.  Reboot between each change.

 

[keith6226]

Still no success.

 

Interestingly, when I turn the "Help" tips on, there appears to be a section at the bottom describing a selection that is not available:

 

 

I have tried using both Chrome and explorer to see if there one was not parsing correctly.

[keith6226]

Looks like the disk(s) set to read-only ... not sure how or why that happened, one of the disks is new ... searching for the setting in the UI

 

[itimpi]

If a disk has been set to read-only due to file system corruption being detected (which is what the syslog is saying), then the recovery process involves running reiserfsck via a console/telnet session.  While in that state you will not be able to change anything on the drive until corrective action has been taken

 

In your case this would involve:

• Stopping the array, and then restarting it in Maintenance mode
  
• Running from a console/telenet session a command of the form
  

reiserfsck --check /dev/md2

(where the md? device corresponds to the disk to be checked).  If using telnet then either keep the window open or run the check under 'screen' as on large drives the check can take some time (losing a telnet window prematurely can abort the process if not running under screen).

 

The reiserfsck run will confirm if there is a problem due to file system corruption, and if one is found will suggest the corrective action.  You might want to check back here before taking the suggested action but the chances are that the recommendation will be to proceed with it.

 

As to why such corruption might have occurred in the first place that is harder to answer.  It is normally caused by a write failing for some reason - but there can be lots of causes behind such an event.