Is my pod dead?


I’ve submitted an issue, tried with the new solid-file-client, but nothing works and trying to use the browser sharing tool, I’ve now corrupted the root .acl of the pod .
For example, preference can’t be accessible anymore.

Is there a way for the owner of a pod to restore all the .acl file to their initial state, please ?
Is there any inrupt admin in this forum?


@Smag0 I also have the same problem with some folders I created using the Pixolid application. AFAIK there’s an issue with the application that causes this issue, being not able to delete this folders afterwards :frowning:

Recently I commented into Gitter Chat and @bourgeoa gave me this steps that could fix the issue (not checked yet):

The way to go is a bit complex.
You can use solid-ide or solid-file-client.
It is a pod backup and restore :

  • copy your “pod A” to a new one “pod B”
    “pod B” need to be accessible by the app Origin and userId of “pod A”
    (check in detail that you have all but the bad folders - they should be listed as errors))
  • delete the original “pod A”
  • recreate a new “pod A” alike the deleted one (same name, userId, …)
    add the needed userId of pod B and Origin needed
  • copy from “pod B” to new “pod A”
    In “pod A” check that everyting is OK. delete the unneeded userId access from “pod B”

that should be all. You can now delete “pod B”.
This process works because solid-file-client makes a recursive copy of all except errors.
You loose everything that is below a wrong folder /foo. If you know or remember some of the folders below /foo/test then you can make a specific backup of these /foo/test

Let me know if you give it a try :slight_smile:


I don’t want to loose my data. And now my /root .acl is damaged.
It don’t think normal that an app can crash an .acl file and that the owner can not restore it :thinking::frowning:


I think this is a fundamental problem with using files to store permissions and could be an ongoing problem.

It needs solving in the server implementation, but given that the way to manipulate permissions is always going to be with an app, I’m not sure it can be solved without a change in the underlying implementation (eg storing permissions in a structure that is not accessible as a file). Could be tricky.


The problem, as I see it, is not with storing access control in files. It is that there is no concept of “pod owner.” This means it is possible to have files on a pod which are not owned by anyone (e.g. a broken .acl). This means that the “pod owner” does not have full control over their pod - they can not delete the .acl or the resources it protects if they are not named in the .acl as the owner and that is guaranteed to be true if the .acl has syntax errors in it or is stored with the wrong content-type.

I think a minimum fix is that the server should cowardly refuse to write an .acl file that has broken syntax or the wrong content-type - allowing users to do this has no benefits and quite terrible consequences - it guarantees that no one except the server admin can access the .acl or the resources it points to.


I’ve raised an issue :


thxs all, an admin unblock my POD, but we must maintain a list of functionnal/corrupted apps