It’s the second time I experienced this. I’m a systems administrator and i manage Cryosparc instances for our users.
When they try to access a directory for which they don’t have rights, they get an access error. So far, so good. But when I set their access rights so they can get to it, the message “Error: Could not list directory” still comes up.
I tried restarting Cryosparc, but it didn’t change anything. Then, a few days later (3-4), access to the directory becomes possible.
This strongly looks like Cryosparc caches some info about access rights and doesn’t check it again until the cache expires. Here, the files are served through NFS. Needless to say, I tried to access the files with the same user that Cryosparc uses and I was able to access the files directly from the same machine. The problems only show up when listing the directory from within Cryosparc.
Please can you describe the context of the attempted access (while running a job? while performing a specific action in the web app?) and where (specific log files or GUI elements) the error messages appear.
What method did you use to modify access rights?
Do the affected files have extended attributes, for example related to selinux?
The rights were set by adding the corresponding user to the owner group in our active directory. I then tested by su’ing to the user with which Cryosparc runs was able to do ls of the directory.
As a side note, when the error shows up like on the picture posted above, the “Up one directory” button is inoperative. The user has to edit the location bar to get back to the previous directory.
Hi, If that helps, I tried the same test accessing a Ceph filesystem and the results were not the same. I tried to read a directory without the correct rights and got the error but i could access it successfully just after fixing the rights.
The difference there is that the rights are managed by regular Linux ACLs, whereas the NFS service uses rights from the AD (and it is not possible to have a detailed view of said rights in the Unix ways, but they are enforced). Still, is there any differential treatment that depends on the announced filesystem type ?
I did one further test on another NFS filesystem and played with permissions. I had no problems. The issue boils down to the fact that on the problematic fileysytem, the rights are not listable, but enforced. Moreover the filesystem can respond “access denied” while at the same time the rights look like to be granted on a directory.
Please update this forum topic if and how you are able to resolve this issue, perhaps by adjusting access controls “at the source” (in Active Directory or on the file server).
Hi,
The issue is still unsolved as of now. The last instance of it (not the one exposed here) took several days before it “disappeared” and access to the directory was possible.
There is nothing more that can be done on the file server since it is a proprietary system. Accessing the directories/files using the user that runs Cryosparc always works. The thing is, that NFS service uses Windows ACLs which are not really mappable to Linux, therefore they are not presented at all. However, the rights are correctly enforced depending on the user that tries to access. The only slightly sketchy thing is that the basic directory rights appear to be 0777, which isn’t true but in the end that information doesn’t prevent the real rights to be applied properly.
The issue only shows from Cryosparc and the fact that the individual issues resolve themselves after some time (minutes up to several days) imply that there is some kind of caching of accessibility metadata…
