mirror of
https://github.com/007revad/Synology_HDD_db.git
synced 2026-04-25 21:55:59 +03:00
[GH-ISSUE #84] Lost access to Storage Manager on DSM 7.2-64561 (DS923+) #33
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_HDD_db#33
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fish-2023 on GitHub (May 31, 2023).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/84
Hi,
I have ran the syno_hdd_db.sh script on my DS923+ and after reboot I still couldn't create an M2 storage pool. I have then run the script again to restore the previous settings before trying anything else. After another reboot the Storage Manager was gone.
This seems similar to #73 but on the final version of 7.2.
The model is missing within the Info Center: https://imgur.com/a/B8SV4WU
I run get_syno_model.sh and this is the output:
I have also checked to see if the config file was corrupt in some way, but this is the only thing diff could see:
I have tried the "Restore DSM configurations" from the "Update & Restore" menu but that didn't help...
Do you have any pointers on how to fix my config?
Thank you
@fish-2023 commented on GitHub (May 31, 2023):
As an additional note, these are the times I have ran the script.
If I remember correctly, after the restore and the reboot, the Storage Manager was still there.
The 3rd run was to include the "-n" since I thought the first run might have not worked because of that. I hope this is helpful.
output:
log:
@007revad commented on GitHub (May 31, 2023):
I notice that the ST8000VN004-3CP101 which was already in the .db files contains 2 new lines that weren't in previous DSM version's db files:
I wonder if the other drives not having those 2 lines is a problem.
There is 1 change that --restore does not undo:
echo 1 > /run/synostorage/disks/nvme0n1/m2_pool_supportYou could try the following:
sudo echo 0 > /run/synostorage/disks/nvme0n1/m2_pool_supportI've downloaded the DSM_DS923+_64561.pat file, unpacked it and attached the default synoinfo.conf and disk compatability db files for you - hoping they'll get your Synology working again.
synoinfo.zip
DiskCompatibilityDB.zip
@fish-2023 commented on GitHub (May 31, 2023):
I'll be able to try the suggested steps in a few hours. In the meantime I'm backing up some important data just in case.
Thank you!
@fish-2023 commented on GitHub (May 31, 2023):
Unfortunately, it didn't work.
I have first tried restoring the whole disk compatibility db, restarted, no change.
I have then copied the synoinfo.conf file, restarted, no change. In this case I see that a few "# Fixed items " sections have appeared at the end of the fine, not sure if it is relevant in any way.
I have then tried to
echo 0 > /run/synostorage/disks/nvme0n1/m2_pool_supportbut I keep getting "Permission denied".I guess the script didn't change any other files? If that's the case then I'll have to reset and reinstall DSM hoping I won't wipe the data (which seems to be an option).
@fish-2023 commented on GitHub (May 31, 2023):
Quick update, I have decided to reset the NAS and reinstall DSM.
I have backed up the settings locally (but they were backed up also on the cloud) and restored them right after the reset. Everything seems to be looking fine 🤞, and I didn't lose any data.
One thing I forgot to mention previously is that I was on 7.1 and I have [manually] updated to 7.2.
This time I have installed 7.2 directly.
Thanks for the support!
@fish-2023 commented on GitHub (May 31, 2023):
OK, wrapping this up.
I guess I didn't really understand how the script[s] worked...
After the reset, I have run the Synology_HDD_db again, restarted and the ran Synology_M2_volume one.
I have now a working volume on the two m2 drives 🎉
I guess the first time I didn't understand what the 1st script was supposed to do and so I reverted the operation. The "restore" operation must have broken something, but I guess the script did what it was supposed to do...
Thanks again, I bought you a beer 😉
@fish-2023 commented on GitHub (May 31, 2023):
The "restore" operation might have caused problems, but on a second run the script[s] worked without any problem.
@007revad commented on GitHub (Jun 2, 2023):
Thank you for pointing that out.
I just tested the restore option on a DS720+ running 7.2 and it had the same issues as you. I found a couple of likely causes and edited them by hand. After that I rebooted and everything was back to normal.
I'll have an updated version of the script online soon (after some more testing).
@fish-2023 commented on GitHub (Jun 2, 2023):
I'm happy to hear that reporting the issue is helping. Thanks again for the work you do