I notice that the permissions on LDP resources and containers that I create using PUT are not the same as their parent “folder”. I would prefer everything to be publicly readable, and i can set that on the top-level folder, but Containers that I create inside of that (and inside of those) not not inherit the ‘r’ permission for all.
Is there a way to force the new containers/resources to carry their parent permissions?
Fastest and easiest way to resolve this, given that your intended parent directory exists now, is to visit the Conductor → Web Application Server → Content Management, and locate your intended top-level container.
Click the properties icon, and locate the menu for Permissions Inheritance (new label) or Default Permissions (old label).
This menu defaults to Off. Select Recursively for your desired effect.
(Direct members would apply this container’s permissions only to resources created directly within this container – not to resources created within sub-containers of this container.)
When you changed the Permissions Inheritance setting, did you also tick the box for Apply changes to all subfolders and resources to apply it recursively to all existing containers in the container you edited?
What is the full version of the Virtuoso binary you’re running? Please provide the full first stanza (above “Usage”) of output from virtuoso-t -? for VOS, or virtuoso-iodbc-t -? for Enterprise Edition.
Please also provide full output of this SQL query –
Just to clarify: When I say “it isn’t recursive”, I don’t mean that it isn’t recursive when I apply it to all existing containers - that does work! What I mean is that it doesn’t “stick”, and when I add new containers or resources those new entities do not have the permissions of the parent container, which is the behaviour I expect/want/need. Should I not be expecting that?
Trying to be explicitly clear – Changing the Permissions Inheritance setting on the parent folder to Recursively, and ticking Apply changes to all subfolders and resources before clicking Updateshould result in all new subfolders (and sub-subfolders, etc.) inheriting their parent’s permissions. It’s not 100% clear to me that these are the steps you’ve taken.
You might also try running with our own Docker Image, which brings you Virtuoso 7.2.6-rc1 (most recently built from develop/7), instead of that third-party Image (which gets auto-built from stable/7).
I have switched to your docker image (tag “latest”). It starts perfectly. I have installed VAL, ODS Framework and ODS Briefcase (Kingsley said these are required for the LDP functionality).
When I browse to the Web Application Server tab, i get the following error:
An error has occurred when processing “/conductor/cont_page.vspx” page.
SQL State
07S01
SQL Message
SR180: Extra arguments to WEBDAV.DBA.ui_size, takes only 2
So I am unable to continue setting-up my LDP server.
OK, it looks like there have been some misunderstandings, and you’ve somehow managed to install VADs built for Enterprise Edition v8.2 on Open Source Edition v7.2… I’ve raised an issue about that, as these should have simply refused to install.
For best results, please discard this Docker Instance.
Start afresh with the openlink/virtuoso-opensource-7 Image (tag latest). Download the latest VOS 7.2 VAD builds, and install at least ODS-Framework and ODS-Briefcase which are needed for LDP. (VAL is Enterprise only, so is not found in this download repo, and is not needed for LDP.)
Please let me know if this resolves the issue with permission inheritance.
There is certainly no user called SPARQL_ADMIN, but there is a role SPARQL_ADMIN, that I have added explicitly to both dba and dav users just to check if that would solve the problem (it didn’t).
Suggestions? (This error didn’t appear on the previous docker Virtuoso I was using, if that helps troubleshoot at all…)
(it would be great to have a solution or work-around for this quickly. I am at the Japan BioHackathon this week… 6 clear days of hacking! I’d love to work on the code that requires the Virtuoso LDP functionality while I am here… if possible.)
@markwilkinson: HT042: Not valid user id "SPARQL_ADMIN" is a known error with Virtuoso Open Source builds which are missing the creation of the special SPARQL_ADMIN user, and can be created manually with the commands:
DB.DBA.USER_CREATE ('SPARQL_ADMIN', uuid());
DB.DBA.EXEC_STMT ('grant SPARQL_UPDATE to SPARQL_ADMIN', 0);
Thus for now the above should be executed on Virtuoso Open Source builds seeking to use LDP.
Please let us know if this resolves the problem for you …
DB.DBA.USER_CREATE ('SPARQL_ADMIN', uuid())
Enter password for dba :
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
*** Error 22023: [Virtuoso Driver][Virtuoso Server]U0001: Conflicting type of existing security object.
at line 1 of Top-Level:
DB.DBA.USER_CREATE ('SPARQL_ADMIN', uuid())
The second command executes happily, but I still get the same error when I try to GET my Container.
I also do not get the U0001: Conflicting type of existing security object. error running the DB.DBA.USER_CREATE ('SPARQL_ADMIN', uuid()) command, which runs successfully for me:
Thus can you confirm the version of Virtuoso being used with the commands below and also if you started with an empty database with just the ODS Framework and Briefcase VADs installed as I did:
SQL> select sys_stat ('git_head');
sys_stat
LONG VARCHAR
_______________________________________________________________________________
4d226f4
1 Rows. -- 1 msec.
SQL> status('');
REPORT
VARCHAR
_______________________________________________________________________________
OpenLink Virtuoso Server
Version 07.20.3230-pthreads for Linux as of Nov 2 2018
Started on: 2018-12-10 14:45 GMT+0
as there must be something different in our test cases …