You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made sure the question is not listed in the FAQ.
Is this a general question and not a technical issue?
I am sure my question is not about a technical issue.
Question
Hey guys,
I believe that many have already been through this situation with virtual dsm, where depending on the tests and the addition/removal of disks, it maps to volume_4 for example, even though volume_2 is available. This is normal, as it saves this path to the disk that was previously mounted, even though it has the same address 0xa/0xb/etc.
What's the problem? None, however if you have services or container files, for example with the path /volume_2 and this path changes to /volume_3 you will need to change all compose paths.
ATTENTION: REMEMBER THAT THIS MAY CAUSE PROBLEMS IF YOU REMAP UNITS THAT ARE BEING USED FOR SYNOLOGY PACKAGES, FOR EXAMPLE. MAKE BACKUP.
Solution:
Login via ssh:
sudo -i
spacetool --synoblock-enum
All disks will appear, we need Syno-Block /dev/sdX
Assuming your virtual disk is like:
- ****** Syno-Block of /dev/sdc ******
- Space Path: /volume3
Let's remap it to /volume2, of course volume2 cannot be in use.
Is your question not already answered in the FAQ?
Is this a general question and not a technical issue?
Question
Hey guys,
I believe that many have already been through this situation with virtual dsm, where depending on the tests and the addition/removal of disks, it maps to volume_4 for example, even though volume_2 is available. This is normal, as it saves this path to the disk that was previously mounted, even though it has the same address 0xa/0xb/etc.
What's the problem? None, however if you have services or container files, for example with the path /volume_2 and this path changes to /volume_3 you will need to change all compose paths.
ATTENTION: REMEMBER THAT THIS MAY CAUSE PROBLEMS IF YOU REMAP UNITS THAT ARE BEING USED FOR SYNOLOGY PACKAGES, FOR EXAMPLE. MAKE BACKUP.
Solution:
Login via ssh:
All disks will appear, we need Syno-Block /dev/sdX
Assuming your virtual disk is like:
Let's remap it to /volume2, of course volume2 cannot be in use.
What if the path /volume2 is being used by sdb and you want to use it?
After restart, map sdc to volume_2:
After restarting, return sdb to the volume you want and have available:
The text was updated successfully, but these errors were encountered: