User can't upload data

[mattc]

Hi,

We are having a problem with one user's OMERO account. Her account is visible in the clients and we can create projects and datasets within that user area. However, when we try to upload any images to her account it fails without any error message. We can upload the same image to other users within her group but it fails again if we try and upload the image for the same user in a different group.

It seems like the user account has become corrupt somehow but looking through the logs I can't see any errors that seem to relate to the problem. The output of 'omero user info' appears as it should be. Is there anywhere else that we should look to diagnose the problem?

This is a new account by the way so if we were to delete the account and recreate a new one we wouldn't be losing any data. I know that deleting users isn't supported as such but is there an under the hood method for resolving a user account issue like this?

Thanks very much,

Matt.

[mtbc]

Dear Matt,

If you zip up your server's var/log/ stuff and send it via http://qa.openmicroscopy.org.uk/qa/upload/ then we'll take a look for clues. It'd be great if you could let us know at what time one of the failed imports occurred and which user is seeing the problems.

Which user are you logged in as when you create these projects and datasets and do the import - the one experiencing the trouble? Do you import images via Insight or the CLI, with default options?

Cheers,
Mark

[mattc]

Many thanks Mark. I've uploaded the logs now. The username is zhangj and I tried uploading it for her this morning (4/10/18) at 10:42. I haven't logged in as zhangj. I was planning to have a try with the cli next.

[mtbc]

Dear Matt,

Thank you for uploading the logs. You are correct: there is a puzzling lack of anything interesting or alarming being logged at the time that you attempted the failed import, or indeed anytime around then. I wonder if the CLI import will give you any more clues. It may also be interesting to see if the user can import as themselves. Are you attempting the import as a full administrator and using the "import-for" sudo functionality? Let us know what command-line arguments you use. It may also be worth trying both importing into an existing dataset and having the import create a new one in case that makes any difference.

Given your previous database issue I wonder if somehow the filesystem is out of step with the database's record of what files are in the managed repository. We can see that it has the top-level directories registered by, as an administrator, trying,

Code: Select all

bin/omero hql --all "SELECT id, name, details.owner.omeName FROM OriginalFile WHERE name IN ('couchman_2', 'zhangj_356') AND mimetype = 'Directory'"


I included the other user as a sanity check for the query: we'd expect a row output for both of the users. (It probably reports "root" as the owner: that's okay.)

We can also see the folders and files registered for the new user (and probably owned by them):

Code: Select all

bin/omero hql --all "SELECT id, details.owner.omeName, path||name FROM OriginalFile WHERE path LIKE 'zhangj_356/%' ORDER BY id"


On the underlying filesystem if you look in the ManagedRepository directory for what folders and files exist under the zhangj_356 directory does the database output match fine with what you see in the filesystem?

Cheers,
Mark

[mtbc]

Dear Matt,

As an additional sanity check, please let us know what output you get from,

Code: Select all

bin/omero fs repos


Cheers,
Mark

[mattc]

Hi Mark,

thanks again for your help. It looks like things have got out of sync as zhangj is absent in those tables:

Code: Select all

omero hql --all "SELECT id, name, details.owner.omeName FROM OriginalFile WHERE name IN ('couchman_2', 'zhangj_356') AND mimetype = 'Directory'"

# | Col1 | Col2       | Col3
---+------+------------+------
0 | 3232 | couchman_2 | root
(1 row)


Code: Select all

omero hql --all "SELECT id, details.owner.omeName, path||nROM OriginalFile WHERE path LIKE 'zhangj_356/%' ORDER BY id"

#
---
(0 rows)

Code: Select all

omero fs repos

# | Id | UUID                                 | Type    | Path                 
---+----+--------------------------------------+---------+------------------------------------------------------
0 | 1  | ScriptRepo                           | Script  | /home/omero/OMERO.server-5.4.6-ice36-b87/lib/scripts
1 | 29 | 0e450e28-c53b-40af-9300-c7e64b569154 | Managed | /OMERO/ManagedRepository
2 | 30 | 906d3707-c760-496d-8088-4f3319d836bc | Public  | /OMERO               
(3 rows)

Following the restore process there was a discrepancy between zhangj's ManagedRepository and what we saw in the omero clients. There were some images and logs in the ManagedRepository which had been added in the interim between the shutdown and the snapshot that we rolled back to. I tried moving those files out temporarily to see if that helped but it didn't make a difference.

Cheers,

Matt.

[mtbc]

Dear Matt,

Thank you, that's informative. Just to confirm: the imports still fail even if you wholly remove the ManagedRepository/zhangj_356/ directory?

Cheers,
Mark

[mattc]

Hi Mark,

I hadn't tried removing the zhangj_356 folder itself. I just did that and now the importing works. Brilliant! Thanks very much!

Cheers,

Matt.

[mtbc]

Dear Matt,

I'm very glad to hear it, thank you for reporting back. Be warned that there may be other strange effects from the DB and FS having been restored from different timepoints: it's largely an "undefined behavior" state. You may want to try a,

Code: Select all

bin/omero admin cleanse --dry-run /OMERO


or suchlike on some rainy day to see if that mentions any issues.

Cheers,
Mark