"rootFileId" translation and "shareId" list removed from OneProvider when moved between virtualisation hosts.
Closed this issue · 21 comments
Good morning.
We ( @alfonpd, @asoreyh ) had published 428 datasets at DataHub and all were working fine until we moved the OneProvider (ceta-ciemat-01, version 20.02.5) from a virtualisation host to another. The migration was perfomed in few minutes and the MV is identical.
From this moment, the OneProvider:
- is not resolving the link stored in "rootFileId" field for every publised dataset in OneZone;
- has removed the "shareId" field in every dataset.
(Rest of the information such as metadata, creation date, was maintained intact).
Thus, the data appears as "deleted" in the shared page for these datasets, for example: https://datahub.egi.eu/share/ee73fc59025fdecf32ac5c3b3a5cf536chd944
Therefore, we like to recover the the "rootFileId" resolving and the "shareId" to enable again the publicly access to the data and to maintain the referenced PiDs, sharing link and whole DublinCore metadata.
Is there any procedure to resotre the information? if there is not:
- Do the information remain stored in any place in OneProvider?
- Can I manually include the information in the BD?
Note that we can develop a script to identify every dataset with their share and to force the inclusion in the BD, but we did not find any procedure or API call to perform this task.
Many thanks in advance. (Several scientific papers are already linking these data and their unavailability could be a seriuos problem through the review process).
Cheers,
Wesołych Świat.
Good morning,
First I would like to understand what happened; in general Oneprovider does not remove any shares just like that, the only cases when this is done is either when a user performs the "remove share" operation, or when shared files/directories are removed from the space.
-
Could you tell me more about the migration? When exactly was it performed? Was the Oneprovider persistence (typically in
/opt/onedata/onedatify/oneprovider_conf) moved properly and was identical on the new host? What is the underlying storage used for the space support; how was it moved? Do you still have access to the previous machine or any backups? If so, and if you have not been changing anything in the space, maybe it would be possible to take a step back and redo the migration. -
Could you attach all the logs matching
info.log*?
/opt/onedata/onedatify/oneprovider_conf/var/log/op_worker/info.log* -
From what I understand, you observed that when you fetch file attributes of a file/directory that was previously shared, you see an empty list in the shares field. Is that correct? FYI, only the share root file/directory should have the share on the list, nested files don't have it.
https://onedata.org/#/home/api/stable/oneprovider?anchor=operation/get_attrs -
What is the nature of this space? Does it change often, or rather contains some datasets that do not change and are published for readonly purposes? For a moment I was suspecting that there may have been a re-import of data during the migration, but from what I see in the storage config, the data was not imported from a preexisting collection, but uploaded into the space...
Cheers,
¡Feliz Navidad!
Hi,
I can provide you some information. I did virtual machine migration.
We have the Oneprovide running as virtual machine under Openstack. We did the migration to another host becouse the new host had better local storage performance.
The migration is a block-to-block copy of the disk and memory, source and the destination must be a pefect copy. When the VM is copied, Openstack start the new VM, assing the network connection and delete the old VM (for this reason, is imposible to access to the old VM). The copy take a long time, but the connectivity is interrupted less than 1 minute.
Then, the "/opt/onedata/onedatify/oneprovider_conf" must be identical.
The storage backend is a external volumen that is attaching to the Oneprovide VM as XFS device.
I'm attaching you the files that you are requesting us.
info.log.zip
The VM was moved: 5 December 2022 at 14:02h
Hello,
Thanks for you answers. Let's assume that the migration is not the cause here then, maybe it's the external storage.
I can see some logs suggesting the Oneprovider is timeouting on operations on the storage backend. Can you make sure that the external volume is reachable from the host, that you can read its contents, and especially that the volume is reachable from the Oneprovider container at the path that is specified in the storage configuration? See the CLUSTERS menu -> Provider's name -> Storages.
The path where the volume is mounted on the host should probably be preceded by "/hostfs/" as this is where host's FS is mounted in the container (unless you did some custom mounts). So for example, let's say the volume is mounted in the VM under /volumes/data/, in the container it should be available at /hostfs/volumes/data and the storage config should specify /hostfs/volumes/data mount point.
Hello,
Yes, the first time that is the volume accessed is a bit slow, then the access is quick and fluid. I copy and paste, volume is mounted and accessible.
/dev/vdb1 on /hostfs/mnt/lagoproject type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
ls -la /hostfs/mnt/lagoproject
total 92
drwxrwxrwx 4 root root 79 Apr 16 2021 .
drwxr-xr-x 5 root root 4096 Mar 18 2021 ..
drwxrwxr-x 1009 root root 69632 Dec 21 15:16 538dae593d8f52ce53ceb768a122b365cha1f4
drwx------ 2 root root 6 Feb 25 2022 .__onedata__deleted
And the latency of the mounted external volume:
ioping .
4 KiB <<< . (xfs /dev/vdb1): request=1 time=1.74 ms (warmup)
4 KiB <<< . (xfs /dev/vdb1): request=2 time=304.0 ms
4 KiB <<< . (xfs /dev/vdb1): request=3 time=90.4 ms
4 KiB <<< . (xfs /dev/vdb1): request=4 time=11.6 ms
4 KiB <<< . (xfs /dev/vdb1): request=5 time=113.0 ms
4 KiB <<< . (xfs /dev/vdb1): request=6 time=19.2 ms (fast)
4 KiB <<< . (xfs /dev/vdb1): request=7 time=28.5 ms (fast)
4 KiB <<< . (xfs /dev/vdb1): request=8 time=168.8 ms
4 KiB <<< . (xfs /dev/vdb1): request=9 time=88.4 ms
4 KiB <<< . (xfs /dev/vdb1): request=10 time=181.2 ms
4 KiB <<< . (xfs /dev/vdb1): request=11 time=152.0 ms
4 KiB <<< . (xfs /dev/vdb1): request=12 time=157.0 ms
--- . (xfs /dev/vdb1) ioping statistics ---
12 requests completed in 2.27 s, 52 KiB read, 5 iops, 22.9 KiB/s
generated 12 requests in 13.2 s, 56 KiB, 1 iops, 4.26 KiB/s
min/avg/max/mdev = 11.6 ms / 174.5 ms / 607.8 ms / 158.2 ms
Ok thanks, and I guess all the expected space files are there? Inside the 538dae593d8f52ce53ceb768a122b365cha1f4 directory?
Do I have your permission to join your space and look around? Maybe I'll be able to understand the problem better.
I keep looking for the underlying cause because the answer to the original question is that we do not have any tools to fix such broken shares, because this should never happen. Maybe writing some specialized scripts will be possible, but it depends on the state of the DB in the Oneprovider and what really happened there.
Yes, the space files are inside 538dae593d8f52ce53ceb768a122b365cha1f4 directory.
To join to the space, is needed the permission from @AJRubio-Montero that is the data and project manager .
Hello,
Yes @lopiola , I'm giving you permission to inspect the space 538dae593d8f52ce53ceb768a122b365cha1f4.
Do you need an invitation token?
Do you want belonging to our virtual organization?
For the latter, you should first join to eduTEAMs (https://www.eduteams.org/#join) and then to the LAGO-AAI VO (https://mms.eduteams.org/fed/registrar/?vo=LAGO-AAI). There is a how-to there: https://lagoproject.github.io/DMP/docs/howtos/how_to_join_LAGO_VO/
Thanks,
Cheers.
Hello again,
Thank you, that won't be necessary. Turns out that as a DataHub admin I'm already an indirect member of the LAGO VO.
I've looked around and I have some observations.
-
All the directories in the space have modification times in 2021. Has there been any activity in the space in the last year (2022)? Any files/directories added/moved/renamed? If so, can you point me to the specific ones?
-
All the shares have been created between 30th June 2022 and 10th July 2022.
-
I can confirm that the "files deleted" error and the ENOENT in the REST API are caused by the fact that the share root directories have an empty share list in their metadata.
My current theory is that during the VM migration, you somehow cloned the persistence from an older snapshot, from before the 30th June 2022. This would explain why all the files are still there, but the share lists in metadata are empty. The main share record is held by Onezone, this is why you can see the shares in the UI. But the share list for every file is held in Oneprovider metadata - so maybe we are looking at an older state of the DB. Does this seem plausible? If so, I think it would be a good idea to verify if anything else could have been lost - maybe a script that will walk through the space and check if all files are there? I've stumbled upon one that is "broken":
Regardless of how all this happened, I have an idea how this could be fixed. It would require entering the Oneprovider console and running a piece of code that will patch the metadata of all affected share root directories and add corresponding shares to their share lists. If you want, I can prepare the script so you can just copy-paste it into the console and run it. Although I'll probably be able to do it not sooner than next week.
Happy New Year!
Happy 2023!
you somehow cloned the persistence from an older snapshot, from before the 30th June 2022. .... But the share list for every file is held in Oneprovider metadata - so maybe we are looking at an older state of the DB. Does this seem plausible?
@alfonpd is still out of office due Christmas to confirm your hypotesis, but It seems that the live-copy of the MV requires previously forcing a "quiesced" dump of the DB. I think we should perform some tests with another OneProvider to confirm this issue (we have one for testing purposes).
On the other hand, uffff, you are right about the the older state of the DB. Reviewing your observations I confirm the oneprovider is showing:
- an older structure of directories and files;
- old JSON metadata for every directory and file.
As it were in 2021. Thus my initial affirmation:
(Rest of the information such as metadata, creation date, was maintained intact).
it is only "true" if you review directly the filesystem. The directory tree was mounted on /mnt/lagoproject/538dae593d8f52ce53ceb768a122b365cha1f4.
The good news are the JSON metadata always is backed up into './metadata' subdirectory when anything is modified.
Therefore:
- All the directories in the space have modification times in 2021. Has there been any activity in the space in the last year (2022)? Any files/directories added/moved/renamed?
Many new directories were added in 2022.
Aditionally there was activity over the directories created in 2021 , principally when publishing the shares, but also correcting metadata mistakes. Every change in the metada is dumped in a file into './metadata' subdirectory. (Additionally, some files could be added to complete a dataset).
About the ones renamed or removed, there are few. In fact, the directory "S0_and_10_1100.0_77402_QGSII_flat" that you have detected is one of the exceptions, because was intentionally removed.
If so, can you point me to the specific ones?
As there are many files and directories, I think we can work with an example of shared directory, for example one similar to the aforementioned:
"S0_and_10_1100.0_77402_QGSII_flat_defaults"
As you can see, through the OneProvider the contain of ./metadata is from nov 2021, however through the filesystem the backups for 30 Jun of 2022 appear:
# ls -alh S0_and_10_1100.0_77402_QGSII_flat_defaults/.metadata/
total 1.6M
drwxrwxr-x 2 1034995 root 24K Jun 30 2022 .
dr-xrwxr-x 3 1034995 root 8.0K Dec 16 2021 ..
-rw-rw-r-- 1 1034995 root 121 Jun 30 2022 ..metadata.jsonld.20220630T134048.351248Z
-rw-rw-r-- 1 1034995 root 3.9K Dec 16 2021 .DAT000703-0703-00000000024.input.jsonld
-rw-rw-r-- 1 1034995 root 4.0K Jun 20 2022 .DAT000703-0703-00000000024.input.jsonld.20220620T151113.849499Z
-rw-rw-r-- 1 1034995 root 4.2K Jun 30 2022 .DAT000703-0703-00000000024.input.jsonld.20220630T134048.982320Z
-rw-rw-r-- 1 1034995 root 3.9K Dec 16 2021 .DAT000703-0703-00000000024.lst.bz2.jsonld
-rw-rw-r-- 1 1034995 root 4.0K Jun 20 2022 .DAT000703-0703-00000000024.lst.bz2.jsonld.20220620T151114.230288Z
-rw-rw-r-- 1 1034995 root 4.2K Jun 30 2022 .DAT000703-0703-00000000024.lst.bz2.jsonld.20220630T134049.570811Z
...
...
...
...
-rw-rw-r-- 1 1034995 root 14K Dec 16 2021 .S0_and_10_1100.0_77402_QGSII_flat_defaults.jsonld
-rw-rw-r-- 1 1034995 root 14K Jun 20 2022 .S0_and_10_1100.0_77402_QGSII_flat_defaults.jsonld.20220620T151113.213609Z
-rw-rw-r-- 1 1034995 root 16K Jun 29 2022 .S0_and_10_1100.0_77402_QGSII_flat_defaults.jsonld.20220629T093711.183953Z
-rw-rw-r-- 1 1034995 root 16K Jun 30 2022 .S0_and_10_1100.0_77402_QGSII_flat_defaults.jsonld.20220630T134047.655527Z
-rw-rw-r-- 1 1034995 root 4.2K Jun 30 2022 .S0_and_10_1100.0_77402_QGSII_flat_defaults.xml.20220630T134047.199656Z
If would be neccesary, we can write code to restore the JSON metadata via REST API.
I have an idea how this could be fixed. It would require entering the Oneprovider console and running a piece of code that will patch the metadata of all affected share root directories and add corresponding shares to their share lists. If you want, I can prepare the script so you can just copy-paste it into the console and run it. Although I'll probably be able to do it not sooner than next week.
Thank you very much!
We will wait for @alfonpd to know his opinion, but If we cannot restore the DB, this script will be nececessary for sure.
The procedure could be:
1- to launch an internal backup of the storage: to avoid unexpected problems.
2- to scan the space for new files: Could be it performed directly on the space or will it overwrite anything?
3- to include JSON metadata via REST: with our script
4- to add corresponding shares to their share lists: with your script.
What do you think about?
Cheers.
Thanks in advance.
Hi,
Sorry I'm still out due Christmas. Your hypotesis is reasonable. But the expected behaviour of a movement a VM in openstack from one node to other must be a block-to-block copy, independently that the image base be older, but is evident this was not the case, and a older instance or snapshot intervened in the movement.
Talking about running a script to restore the BD with a script, we can do a snapshot to backup the Oneprovide VM and do the procedure stepts that @AJRubio-Montero say.
The fact that there are JSON backups in ./metadata will certainly be a life saver. I think that we should be able to recover the state of the space and all shares from before the unfortunate VM movement, but it will require careful planning and some scripting, probably on the Onezone side too... I'll be more available next week so we can get back to that, for now it would be best to avoid doing anything in the space, because the fact that the storage is desynced with metadata can cause a complete mess upon any modifications.
A backup - that you can always do :) For sure you should do one before we start the recovery operations, so we can go back in case anything goes wrong.
Ok, if @AJRubio-Montero give us the Ok, I do a backup and can run the script.
Hello again,
Of course if you can still somehow restore the state of the DB from before the migration, it would be the best way to go. Otherwise, @AJRubio-Montero your suggestion for the course of action is reasonable, but we need to work on some details.
Firstly, since the space metadata is desynced, we cannot depend on root File IDs referenced by the shares. We will have to rebuild the mapping. Looking at the space, I suppose that the share names were identical to directory names? And all the shared directories were placed flat in the top space directory? If these two are true for all of them, it should be easy to find matches for all shares. Then I will need to run a script on the Onezone level to reattach the shares to different root File IDs (as during rebuilding of the space metadata, different IDs than before will be created). Finally, you will have to run a script in the Oneprovider to add the shares to shareLists for each directory.
Secondly, we need to carefully choose the right strategy to rebuild the space metadata. I can see three ways:
-
Write a script to scan and compare the storage and the space for changed / deleted / added files and perform adequate changes required to bring the space to desired state.
-
Create a new space and run storage import to automatically import all the data from the storage. Then run your script to add JSON metadata via REST.
-
Create a new space with a fresh empty storage and write a script that will walk through the old storage and create all files / directories in the new space and add the JSON metadata.
IMO, 1) is quite risky. The script will be hard to write due to edge cases and it's hard to predict what can go wrong since the metadata is desynced with the storage. I would avoid this one.
Ad. 2) and 3) have this downside that you will get an new space ID and different File IDs for all your data in the space, but the share/handle IDs and public links will stay the same as before.
Ad. 2) is an easiest one, it will reuse the existing storage, but in a new space. However, due to import, all the data will have no owner assigned. What is more, if anything goes wrong (especially in case of any modifications), the original storage will be affected.
Ad. 3) is a bit harder, but quite safe - you can retry as much as you want, creating new spaces until you get it right (the old space and storage stays untouched). I would recommend this one.
Regardless which one you choose, when the metadata and storage in your space is already aligned, you will need to infer the mapping for root directory IDs for each share and send it to me. You will need to list all shares (in the old space), check their names, find a directory (in the new space) with the name and get its ID. I'd prefer a JSON with a single object where key is a share ID and value is the File ID of the root directory, e.g.:
{
"7dbfa5e634d53f4a6f89671f834e8f71ch8211": "0000000000523AB767756964236434643...",
"190887ad347b2cb1e0bed7a84eda568ach1f97": "000000000036434643567756964223AB7...",
"...": "..."
}
I can see 426 shares in the space, so we need this many mappings.
Based on it, I can run my script to reattach your shares and prepare your script to add the shares to file metadata.
Hello Łukasz,
a) @alfonpd confirmed me the previous DB cannot be recovered.
b) @asoreyh and collaborators are using this space in production. They have scheduled stopping next monday 16. Then we will put the original storage in read-only and we will back up it to another place.
Following your recommendations, we should choose between the (2) or (3).
I personally bet for the (2) option, but finally putting whole files under the "root" owner of our VO (i.e. my ID).
I suppose that the share names were identical to directory names?
Yes and not. There is a limit of characters in share names and we had to cut these name when create them. (Extending this limit is an enhancement that we would request as another issue).
And all the shared directories were placed flat in the top space directory?
Yes, always.
You will need to list all shares (in the old space), check their names, find a directory (in the new space) with the name and get its ID. I'd prefer a JSON with a single object where key is a share ID and value is the File ID of the root directory.
OK, we will do it. Additionally another JSON with "share ID" : "folder name" to avoid problems.
Also, we start to coding the script to recover the JSON metadata file. It will be the reverse of others that aready were used to patch metadata ( such as this : https://github.com/lagoproject/onedataSim/blob/dev/patches/metadata_patcher_1.1.0b.py). The only drawback it is via REST and it will be very, very slow.
Thank you very much.
Cheers.
Hello,
but finally putting whole files under the "root" owner of our VO (i.e. my ID).
Unfortunately changing the owner is not possible. We have this on our roadmap, but for now, you would stay with files owned by no one. Depending on the permissions on the storage, this can (or not) cause some additional problems with later modifications, as the file owner is permitted to do more operations on it. This is one of the reasons I'd recommend 3). In fact, now I'm thinking; if you just mount a Oneclient in the new space and do an rsync from the old storage to the Oneclient's mountpoint, you should get a nice copy quite easily, and they will be owned by you.
There is a limit of characters in share names and we had to cut these name when create them.
I see, but I guess if all share names are unique, it should be possible to do prefix matching.
Extending this limit is an enhancement that we would request as another issue
In Onedata version 21.02.* the limit has been bumped to 128 characters. We should see this version on DataHub in a couple of months.
it is via REST and it will be very, very slow
FYI, it's also possible to set JSON metadata via Oneclient using the xattr command, like below. Maybe this will be helpful:
root@4e8d1a21aa05:/mnt/oneclient/demo-2022-11-10# xattr -w onedata_json {\"c\":\"d\"} directory_name
root@4e8d1a21aa05:/mnt/oneclient/demo-2022-11-10# xattr -l directory_name
onedata_json: {"c":"d"}
org.onedata.guid: Z3VpZCNhNjc0MjQyO...
org.onedata.file_id: 000000000052756C677...
org.onedata.space_id: 8a18d0d7bdc95...
Good luck with the recovery and let me know when you are ready.
Cheers
Hello @lopiola ;
We did'nt forget this issue, but we had experienced low performance while copying the data from the old space to new one, and we spent weeks. (We will open other ticket about the tricks to correctly configure an Oneprovider, but we need compiling some logs and procedures).
Focusing on this issue, the 429 datasets previously published have been copied from "LAGOsimBak" space (renamed and read-only) to a new space called "LAGOsim".
You will need to list all shares (in the old space), check their names, find a directory (in the new space) with the name and get its ID. I'd prefer a JSON with a single object where key is a share ID and value is the File ID of the root directory.
OK, we will do it. Additionally another JSON with "share ID" : "folder name" to avoid problems.
I have written an script:
https://github.com/lagoproject/onedataSim/blob/dev-ajrubio-montero/patches/test_shared_linking.py
that provides two files:
20220220_dict_share_file_ids_extended.zip
1- The first is the one you are requiring, with the format: {'shareId':'rootFileId'}
2- The other file shows the correspondence among current, actual and backed-up values, with the format:
{'shareId':{
'rootFileId': { 'current': "the one registered in OneZone",
'actual': "the correct one",
'match': "are they identical?"},
'name': { 'current': "the one registered in OneZone",
'actual': "the correct one",
'backed-up': "the stored in the metadata backup file",
'match': "are they identical?"},
'publicHandle': { 'current': "the one registered in OneZone",
'actual': "the correct one",
'backed-up': "the stored in the metadata backup file",
'match': "are they identical?"}
}
}
If you need other files, you do not hesitate require me them.
In Onedata version 21.02.* the limit has been bumped to 128 characters. We should see this version on DataHub in a couple of months.
128 chars will be enough. I think we can directly change it with "Modify share details" call, because the handle' metadata and the OAI-PMH already store the complete title.
For example for this record has the share name as "S0_and_15552000_570000.0_77402_QGSII_volu_HEcuts_ ", but the title is "S0_and_15552000_570000.0_77402_QGSII_volu_HEcuts_defaults" as well the one in OAI-PMH.
Than you very much in advance.
Cheers.
Hello @AJRubio-Montero,
I've prepared the scripts both for Onezone and Oneprovider and tested them in a test environment. The final effect is as expected - the shares get nicely reattached to another directory in another space.
I was about to run the Onezone script for the mapping that you provided, but then I realized that it's only 142 entries long, while there are 426 shares in the original space. I've taken a look at your script, seems that you were struggling to list the shares from Onezone and tried a different approach. But you should use another endpoint for that:
curl -H x-auth-token:$TOKEN https://datahub.egi.eu/api/v3/onezone/spaces/538dae593d8f52ce53ceb768a122b365cha1f4/shares
(just export the TOKEN variable as an access token for Onezone REST)
then you can get the share information one by one:
curl -H x-auth-token:$TOKEN https://datahub.egi.eu/api/v3/onezone/shares/$SHARE_ID
and find its name, which should allow you to do prefix matching and find the corresponding directory.
I'm waiting with running the script for the full mapping. Let me know if you have any problems with completing that.
Hello @lopiola,
I realized that it's only 142 entries long, while there are 426 shares in the original space.
Pufff, I'm an sloppy developer. Yes, there are 426 shares.
I had got a minor number of shares because I should have used "offsets" for overcoming the 1,000 limit when I lookup for backup files in metadata directories. However the approach is the correct, because I have to check firstly the existence of the metadata backup, which contains the share link and the handle PiD and other information. It is a bottom-top checking.
In any case, I have added your recommendation into the script as an additional test. Therefore, if the set of "shareIds" obtained by a method is not identical to the set of "shareIds" obtained by the other method, it will trigger a warning.
These are the files now:
20230227_dict_share_file_ids.zip
I apologize for the inconvenences.
Thanks.
Cheers.
Hello again,
No problem, thank you for the updated mapping. I've found some spare time to run the Onezone reattachment script today and it went smooth. You should now see all the shares in the LAGOsim space, and none in the LAGOsimBak space.
They are not yet functional, for that you have to run the Oneprovider reattachment script. Please follow these steps:
- Copy the
20230227_dict_share_file_ids.jsonfile to/tmp/map.jsonin the Oneprovider container. - Exec to the container
bashshell and attach to the console by running the following command:op_worker attach- you should get an Erlang shell. - Copy-paste the below script 1:1 into the shell and press
<ENTER> - The script should give you a nice output as it works it way through the shares, finally informing (hopefully) about successful reattachment of 426 shares and displaying an "ok".
- The script is NOT idempotent; in case of any exceptions/failures, do not try to run it again. Just get back to me and we will work it out.
- Consider copying the output and saving it somewhere so that we can go back to what happened in case of any problems.
- Exit by hitting
Ctrl+Ctwice.
f(),
ReadMappingFile = fun(Path) ->
{ok, FileContent} = file:read_file(Path),
Json = json_utils:decode(FileContent),
maps:map(fun(_, ObjectId) ->
element(1, file_id:unpack_guid(element(2, {ok, _} = file_id:objectid_to_guid(ObjectId)))) end,
Json)
end,
Mapping = ReadMappingFile("/tmp/map.json"),
rr(file_meta),
ReattachShareOneprovider = fun(ShareId, NewRootFileUuid) ->
{ok, _} = file_meta:update({uuid, NewRootFileUuid}, fun(FileMeta = #file_meta{shares = []}) -> {ok, FileMeta#file_meta{shares = [ShareId]}} end),
io:format("Reattached share ~s to file ~s~n", [ShareId, NewRootFileUuid])
end,
io:format("~n~n"),
lists:foreach(fun({ShareId, Uuid}) ->
ReattachShareOneprovider(ShareId, Uuid)
end, maps:to_list(Mapping)),
io:format("~n-------------------~nSuccessfully reattached ~B shares.~n", [maps:size(Mapping)]).
Done, verify if the shares are functional.
Best of luck, please let me know how it went!
Lukasz
Great @lopiola !
Your script worked fine. Datasets are available again.
Indeed, the script will be very useful for the future. For example, if any dataset was accidentally removed or for testing purposes.
(Now, I have to recover the JSON metadata from backup files, but it was under my responsability).
Thank you very much for your support.
Cheers.
You are welcome, I'm glad it worked.
I'm closing the issue then, feel free to reopen in case of any other problems.
Cheers.