Bug #5234
closedReplication -- user does not have permission to update access rule for data file
0%
Description
I have a group of files that aren't replicating with the error message that I don't have permission to update access rules for one of the data files. I'm the administrator and both databases (xml_access) show I have all(7) allow permissions on the file via the data-managers group.
<frenockm_> knb 20101029-10:24:30: [ERROR]: ReplicationHandler.handleSingleXMLDocument - Failed to write doc pisco_recruitment.1374.1 into db because User: uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org does not have permission to update access rules for data file pisco_recruitment_UCSC.1 [ReplicationLogging]
<jing> then this is a bug. somebody change the code and the replication rules is broken.
<jing> you may file a bug about this.
Updated by Jing Tao about 14 years ago
Mike:
Can you double check if uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org is the administrator in metacat.properties.
I remember the replication between pisco and knb is single way: PISCO --> KNB. It should NOT have the process to write eml documents and data files to PISCO. Is it another replication?
Updated by Jing Tao about 14 years ago
<frenockm_> I am an administrator in metacat.properties.
<jing> okay.
<frenockm_> the replication is from the UCSB server to OSU server
<frenockm_> the UCSB server also replicates to KNB
<jing> so you are an administrator of OSU.
<frenockm_> yes, and the UCSB PISCO server.
<jing> and the replication is from UCSB to OSU.
<frenockm_> yes
<jing> if this is the case, this is a major bug.
Updated by ben leinfelder about 14 years ago
I don't think this has anything to do with the "administrator" defined in the metacat.properties file.
I looked at the xml_access table on KNB and saw that another metadata file was already controlling the permissions for this data file:
http://knb.ecoinformatics.org/knb/metacat/pisco_recruitment_UCSC.18/default
This can't be the first time something like this has come up, but I'm not sure what the approach is when we have two metadata documents attempting to specify access control for the same data file.
Updated by Jing Tao about 14 years ago
Ben:
This happened during the replication. In the replication the access rules should be bypassed. In the early stage, I think we used the user - "null" which had all permissions to all documents and data. I think somebody thinks "null" is not good idea and changed it to the administrator (but i am not 100% sure about this).
Thanks,
Jing
Updated by ben leinfelder about 13 years ago
In v1.9.5 we use a null replication user to perform replication (rather than the user_owner from the xml_documents table). When replication is complete for a document, we set the user_owner and user_updated fields with information passed in the document info block.