I don't have access to my own existing container

[kahramanbayraktar]

Pod browser says I don't have access to my own container.

I can view the container on the server provider's website:

How I ended up with this situation:

• I opened the music container and clicked the delete button many times (I need to do this because of another issue #294) to delete the inner container and its resource file.
• I returned back to the root folder. The music folder was still available.
• I clicked the music folder and it opened with the error message "You don't have access to this resource: https://karr.solidcommunity.net/music/.".

I also notice that there is an earlier 404 error you can see on the console that may be related to the issue.

[brownhoward]

Reviewing the workflow described, it seems that at some point the Access Control List (ACL) associated with the /music Container was corrupted or at least incorrectly updated so that you no longer have access to the Container. If you check the Network tab in the browser Developer Tools, there is probably an error when trying to GET /music/.acl.

So a couple of things:

1. I'll talk to the development team to see if we can understand why this happened
2. As you were using a Pod on solidcommunity.net, I would recommend you contact the Admins for that server to see if they can help fix the bug (unfortunately we cannot do anything from our side). https://github.com/solid/solidcommunity.net/issues

[kahramanbayraktar]

Thank you so much, Kevin.

[brownhoward]

Response from the development team basically confirms the suspicion that the ACL got cleared and your control access was removed from it. As such, the only short-term fix is for the server admin to reset the ACL.

As this is a known issue, an update of the Solid Specification (https://github.com/solid/specification/pull/264) has been proposed where the "Owner" of a Pod data storage will can be defined. (e.g., the owner has implicit control of a data storage). In this way, once implemented in the different Solid servers, the "Owner" should never get themselves in the situation you are observing as they will always have control access to all containers/resources in the Pod.

[bourgeoa]

@kevin-inrupt I just checked on server-side at solidcommunity.net :

• /music/.acl exists and is correct (as stated above solid/solidos do not give any error)
• /session do not exist and I don't see why inrupt/podbrowser is asking for it
• error 403 do not relate usually to ACL issues, but mostly to origin issues.

For the time being and without further information I don't see an issue on the pod itself, nor on solidOs.

@kahramanbayraktar can you confirm that access is correct using https://karr.solidcommunity.net/music/ and that your problem relates to using inrupt's podBrowser

[bourgeoa]

The .acl is the following :

@prefix : <#>.
@prefix n0: </.acl#>.
@prefix n1: <http://www.w3.org/ns/auth/acl#>.
@prefix music: <./>.
@prefix c: </profile/card#>.

n0:owner
    a n1:Authorization;
    n1:accessTo music:;
    n1:agent <mailto:[email protected]>;
    n1:default music:;
    n1:mode n1:Control, n1:Read, n1:Write.
:16222816445555109218789133343
    a n1:Authorization;
    n1:accessTo music:;
    n1:agent c:me;
    n1:mode n1:Control, n1:Read, n1:Write.
:16222816445567588118762527611
    a n1:Authorization;
    n1:agent c:me;
    n1:default music:;
    n1:mode n1:Control, n1:Read, n1:Write.

@kevin-inrupt I think to remember an inrupt issue where acl:accessTo and acl:default are not considered if they have a different subject. Is this still an open issue at inrupt ?

@kahramanbayraktar Could you try to use the sharing-pane of music in solid/solidos. If you try to edit it shall be rebuild with a unique subject. This is only a workaround to the inrupt's issue.

[Vinnl]

@bourgeoa I think you're referring to this issue: https://github.com/solid/node-solid-server/issues/1596

[bourgeoa]

@Vinnl May be it is linked to this issue But seems somehow different.

[ThisIsMissEm]

@kahramanbayraktar is this issue still happening, if so, please let us know how to reproduce it, otherwise we'll close this issue.