WOW! A NEW installation and it already had System Shares and pools assigned?
I’ve NEVER seen that happen before…
Does it also have any NFS/SAMBA/SFTP assignments?
It seems to have imported the pool, shares & snapshots
But
The masterpool is disabled ???
And no Samba.
Umm, well, I would suggest you somehow erase the boot drive and then reinstall… sounds like it did an update rather new install…
Been a while since I did a clean install from that older version, and in fact, I discovered some weirdness in recreating pools and such with 4.0.6… or was it 4.6…
Whatever, the glitch bothered me so much, and since it was my BACKUP NAS setup, I installed the TEST branch and problems solved!
So, my MAIN NAS still runs on 4.1 and my backup NAS runs on 5.0.8 and I really like it so far. I won’t upgrade my MAIN NAS until the 5.0.8 or whatever the next release is.
The other option is maybe … hmmm…
- Reboot with what you have with all the drives (except boot drive) disconnected.
- The system will report all disconnected drives and shares
- Delete all the System/Shares, all snapshots, all pools (not boot)
- Remove/delete all the disconnected disks in the System/Disks display. (not boot)
( if problems with step 3 or 4, stop and inform us please.) OR (try to jump to step 9a and try 3/4 again)
- Reboot with the disks still disconnected and make sure the Storage stuff is empty except for boot drive.
- Do all software updates without the disks connected (except boot)
- Reboot when you are satisfied everything is clean and updated.
- Shut down.
- Reconnect all drives, boot, and don’t touch a thing. Don’t auto import or anything.
9a) At this point, if it automatically repopulates everything, then I suggest repeating step 5 and then click on the Rockstor Version to bring up the System Software window (or select System/Software Update) and switch to the testing version.
9b) Once all the updates (6) for testing done, then do 7,8,9 again.
9c) If it still auto imports, scream for help! Have a beer! Yell at me!
- If either software version works, comes up without importing stuff, then smile and take a break.
Let us know if any of this work please…
Thanks @Tex1954
The other option is maybe … hmmm…
1. Reboot with what you have with all the drives (except boot drive) disconnected.
2. The system will report all disconnected drives and shares
Done Screen shot below
3. Delete all the System/Shares, all snapshots, all pools (not boot)
No Snapshots showing on Snapshot Screen
Trash can selected for the first share at the top of the list gave this error
Stopped the process to report.
Over to the experts
@Tex1954 Re:
Not so, as @Mike-B indicates the following:
At the point directly after the import from any one disk member, the pool looks to have mounted, otherwise it could not have discovered the Shares (btrfs subvolumes). With the RED “Disabled” relating only to quotas (and the orphan qgroup warning on the console), not the shares themselves. So the anomaly here is that the pool detail page then shows the pools as not mounted!
Exactly. But note that
Share Exports are not expected to be imported, that would be from a config back-up. Pool import only imports the pool and it’s parts: shares/clones/snapshots.
@Tex1954 Again, we need to refrain from advising that folks delete all their data: delete means it will try it’s hardest to remove all data (not just the Database/Web-UI references):
But you did say to remove all data drives: nice:
But failing to remove Pools/shares that cannot be mounted is a design decision. Our ‘Delete’ option is to delete the data (with warnings), if we can’t mount to do this, we bail:
Hence @Mike-B reported:
Failed to delete the share (Books). Error from the OS: Failed to mount Pool(Master-Pool) due to unknown reason.
Where we know the reason: all it’s members are disconnected. So we can’t perform the delete.
What we are sorely missing currently is a feature to just remove the Database/Rockstor knowledge - and do nothing else; drives attached or not: that would be ideal in this situation. And @Flox has some ideas on this - and we have cleaned some things up ready. But for reset options as-is, we currently only have:
- a complete Database reset: hard-reset procedure in developer docs
or - The more approachable option, with less ‘artefacts’, is the reinstall - much preferred in almost all non development situations. And only a few minutes on modern hardware.
Which @Tex1954 suggests here, and we have established that a reinstall via our installers auto-wipes the target drive. There was a misunderstanding, now addressed, where the pool was though to have been auto-imported. But an import was enacted by @Mike-B: quoted above.
Given @Mike-B is already familiar with a re-install (rather more familiar than I suspect was expected 
). That is the easiest and cleanest route to a complete system reset.
@Mike-B Sorry about this, but I’d really like to understand what is going on here; and of course to see you sorted Pool import wise. And to improve our docs where needed.
Currently your last attempt seems to have worked with the possible distraction of the red Disabled indicators relating only to quotas (nothing else): that can happen and can be sorted easily by disabling quotas at command line and re-enabling: something for later however.
On your last report you don’t indicate an error on the import: this is good. And remember that you only need to import once from any single member (in docs) asming it works for that member. All other pool members (drives) will then be updated/imported according (only after a page refresh thought!!). This single member import appears to be what you did last: all good. To double check this, and to see if the Web-UI was just lagging behind reality - and throwing us all. A fresh re-install: then import (only once from a single member) then after the shares show up (like last time): reboot. Ignore the Disabled quotas reference.
That only relates to the Quota status. Again we can deal with that easily once we are certain all is OK with the import. And rember pool import does not import anything other than the Pool and it’s sub-parts (shares etc) Exports are setup by hand again or via a backup config restore. Not a pool import. Again this is an intentional decision. Pool import is not configuration import: just Pool (and parts).
Hope that helps. I think it has basically worked but our Web-UI is distracting you some how! Again this is to be our focus in the next testing phase: a more ‘live’ Web-UI experience, i.e. not having to refresh each page, sometimes 2 or 3 times to see the actual Truth of the matter. We are still old-fashioned in that regard: but our recent back-end updates open the way to have a more live Web-UI next go-around.
1 Like
Thanks @phillxnet
Think I will read through it again, (mow the lawns before the rain whilst mulling it over) and think about the next move. 
Cheers for now
Recapping for a restart
(Currently only the root drive is connected)
Shut down and plug in the usb drive from before, connect the kb and monitor
Reboot (bios will recognise the usb), run through the install procedure.
Once the web ui has run up,
shutdown and remove the usb
Reboot check web ui looks ok
Shutdown connect data drives
Reboot
Through the web ui, import only the first data drive, when the shares show, reboot and check the state of the system, if no change refresh the page a few times reboot again and report the results.
1 Like
YIkes… I think my brain has melted and is beginning to drain out…
GOOD LUCK WITH Rockstor*Nth installs… been there, done that… brain melts…
Completed all of the above but have not updated from the generic install.
No real change to report,
Refreshed and rebooted numerous times to no avail.
Screen shots taken if needed.
Tried to initiate the rockons but systen needs a share, does this mean the shares are still not available or would new rockon shares be required anyway?
I did find the dropdown list of rockon shares, would the “overall” rockon share be the Rockon-Root share? Where all the rockon shares reside?
I’m thinking if that is the case, by selecting it, all the other rockons would be initiated
So have you just done a fresh re-install, and if so did you then try an import? If not let me know here and we can try something else.
Incidentally we now have the following to address a potential confusion within the Web-UI:
Don’t move to Rock-ons re-config until you have the Pool imported. It is the first step in re-instating a prior data pool.
What is the output of:
mount
and
btrfs fi show
both run as the ‘root’ user.
That would help yes: lets see your current Web-UI state via Pools overview page screenshot.
Cheers.
1 Like
@Mike-B From the Pic your Pool is imported and mounted.
Quotas are disabled but that does not matter just yet: we can sort that in a bit. And it won’t stop any important function.
How about a share overview Pic?
@Mike-B Likewise your share-overview (and prior screen-shots of the terminal) shows all shares as having been impoted and mounted just find: except for the “Disabled” quota status: again not a problem over-all.
You can, for now, ignore the Disabled Quota status.
Thus far you look to have a successful Pool import: what part of this state is not ringing true for you currently?
Useing the App X-plore has provided excellent service in moving files in and out of Rockstore, however with the new motherboard it doesn’t seem to be able to access anything. Now having been advised that the disabled quotas isn’t an issue I will redirect my investigation into accessing Rockstor. Possibly the graphics card is not functioning through the ethernet connection, or the picture might change when the rockons are reset.
Could that now be achieved?
Netdata and Jellyfin will be needed as monitoring the cpu temp of the new mb when viewing 1080p movies is a major concern and the reason for the change.
Also
Would it now be appropriate to update to the latest testing version?
Just noticed that Samba has not been initiated, possbly why the files cannot be accessed?
@Mike-B Re:
You currently have a Rockstor install that has only had a pool imported - it is not yet configured with any form of export or Rock-on. There are no exports setup as of yet. And no Rock-ons configured. Do you have a config-backup file as per:
https://rockstor.com/docs/interface/system/config_backup.html
A configuration backup file could restore most configuration, now that you have imported the pool. But if you do not have one then you have to setup form scratch: but using the existing shares for all Rock-ons. I see you have some used before and named sensibly.
There are two parts to restoring a system: the pool import (now done) and the configuration restore. The latter can mostly be done with a config-back file, or by hand. If you don’t have a config-backup saved then you will have to enable the export services you need and re-install Rock-ons being very carefull to use the exact same shares as before. Again you have named things sensibly so that should be easy.
Let the forum know your next most imidiate requirement. All data that was there before is very likely there now. That is the Pool import thing. You just need to setup/re-establish your config.
- Data first
- Config second
This split is required as folks don’t always want to re-instate a prior systems config. But they often want to re-establish prior data.
I would say you have all data and individial application (Rock-ons) config by way of for example the dedicated shares named as such:
- Jellyfin-Config for example
likely relates to the configuration stored/used for your last Jellyfin Rock-on install.
So did you have a config-back file from before: if not then you can setup manually again. But all data is already available as the Pool import looks to be good.
Let us know when you fancy fixing/re-enabling the quotas by the way.
2 Likes
Thanks @phillxnet
Unfortunately there was no config backup so its down to a manual reset.
Thursday will be a time to readdress the issues.
Thanks again
1 Like
@Mike-B Re:
That is not necessarily all that bad: depends on the complexity of your setup. List the things you need to re-config (you have already done a reset by way of the re-install) and folks on the forum can point you at the relevant doc section. All your Rock-on setup will still be intact, you just need to re-enable exports and setup the Rock-on service ready to start re-adding Rock-ons.
A quick list of what is needed can help folk help you re-config what you need/had-before.
Hope that helps.
2 Likes
Thanks again @phillxnet
Have now updated to the latest test version, all running fine except a few glitches in the dashboard page, initial observation immediately shows the fancy spider grapihic isn’t showing. No worries there.
Samba started
Now
The process for accessing shares.
Take note of the name and size (as showing on the shares page)
Delete the one showing on the shares page (with the rubbish bin icon)
Start a new share with the original details
Except all the shares are currently showing an equal size???
Will not proceed any further until advice received as I wouldn’t wish to loose any data.
@Mike-B We are getting there. I’ll take points in order:
A web-broswer page refresh may help there, the browser may have hold of some old stuff.
Not sure what that is actually !
Re:
NO. There is no requirement to Delete anything. Please drop all notions of deleting anything here.
You have only to create Exports and or (Rock-on installs). All Shares are your old Shares imported along with the Pool import. You just need to create Exports (and or Rock-on installs) of those existing Shares. Delete means Deleting data. You do not want that or you would not have gone to the trouble of importing your old Pool.
Exactly, and agreed. This is why we were stepping very carefully before hand (and now). Once the pool is imported you should have all data available again. And with config restore all exports and Rock-ons could also have been restored - but without that we just need them to be re-established with new Exports, and new Rock-on installs (both using existing Shares - the same ones as before) i.e. Syncthing share for Syncthing Rock-on. No Deletion of any share is on the cards here (except maybe the rock-ons-root - which I don’t remember seeing on your data pool anyway - assuming you used this for no actual data or config).
This is a side-effect of the import. Share size is currently a cosmetic. All shares can grow to the size of the pool; only not all at the same time of course. We don’t enforce the share size currently: it requires quotas and they are costly performance wise and were a little flaky for a while back there. But they are getting more stable as time goes by.
- How did you access your shares’ data from other machines before?
Answering that question helps folks here on the forum help you re-setup the Exports (of your old shares now imported), or the Rock-ons: e.g. Syncthing or Emby etc.
Incidentally, such interactions here always help to inform where our docs are not doing what they are for. So all good.
And keep in mind:
- Share = a share of the pool data space, like a piece of the data pie.
- Export = exported access of a Share’s data.
Once you are all setup again you can take a config save, so this can all be automated another time: if need be.
Hope that helps. And don’t delete anything .
1 Like