Open Microscopy Environment

Is there a recommended way to move the ManagedRepository directory and allow additions to the current user accounts? After reading through some of the documentation and forum posts, I stopped the server, copied over the directory to the new location (and changed the name of the old directory to avoid confusion), executed "bin/omero config set omero.managed.dir /home/omero92/ManagedRepository", and restarted the server.

Now I can view all the files with the OMERO client, but when I try an import operation, I get the following:

Code: Select all

$> bin/omero import -- --debug=ERROR /tmp/01_Zoom.png
Using session c4de4243-b6fe-43a7-be22-d373cec5132b (patrick@localhost:4064). Idle timeout: 10.0 min. Current group: test_grp
2015-05-14 11:34:23,830 176        [      main] INFO          ome.formats.importer.ImportConfig - OMERO Version: 5.0.6-ice35-b53
2015-05-14 11:34:23,841 187        [      main] INFO          ome.formats.importer.ImportConfig - Bioformats version: 5.0.6-ice35-b53 revision: 33b1150 date: 10 November 2014
2015-05-14 11:34:35,397 11743      [      main] ERROR        ome.formats.importer.ImportLibrary - Error on import: Directory exists but is not registered: CheckedPath(patrick_3)


All the files below the patrick_3 directory within the new ManagedRepository are intact. If I create a new user (or utilize an account that doesn't have files or a directory under the new ManagedRepository), the import operation runs as expected and I can see the new files stored in the expected location.

I figure there is something else that I need to set or do to register the "old" users' directory locations. What have I missed?

Hi ClayB,

ClayB wrote:Is there a recommended way to move the ManagedRepository directory and allow additions to the current user accounts? After reading through some of the documentation and forum posts, I stopped the server, copied over the directory to the new location (and changed the name of the old directory to avoid confusion), executed "bin/omero config set omero.managed.dir /home/omero92/ManagedRepository", and restarted the server.

...

All the files below the patrick_3 directory within the new ManagedRepository are intact. If I create a new user (or utilize an account that doesn't have files or a directory under the new ManagedRepository), the import operation runs as expected and I can see the new files stored in the expected location.

I figure there is something else that I need to set or do to register the "old" users' directory locations. What have I missed?

When the renaming is detected there should be a line logged to var/log/Blitz-0.log of the form:

Code: Select all

Data directory moved: $OLD updated to $NEW


Could you either check for that line or upload your log file for us to look at? Also, could you provide the output of:

Code: Select all

bin/omero fs repos


Something seems to have gone wrong during the renaming. It should be possible to update the DB to have all the directories point at the same repository to correct your situation.

Cheers,
~Josh.

Yes, the change line is in the Blitz-0.log file:

Code: Select all

2015-05-14 11:11:50,209 WARN  [      o.s.blitz.repo.AbstractRepositoryI] (2-thread-2) Data directory moved: /OMERO/ManagedRepository updated to /home/omero92/ManagedRepository


I can attach the last "few" line of the Blitz-0.log file if that isn't enough.

Here is the result of the bin/omero fs repos command:

Code: Select all

Created session 3554aea9-c33e-4a04-bdf0-75d8a4fd9de7 (root@localhost:4064). Idle timeout: 10.0 min. Current group: system
# | Id  | UUID                                 | Type    | Path               
---+-----+--------------------------------------+---------+--------------------------------------------------------
0 | 1   | 4f70f5bc-4809-4084-a654-20680c81a140 | Public  | /OMERO             
1 | 2   | 49de94f0-d591-4c1a-a159-4bf0b46cc11f | Public  | /OMERO/ManagedRepository
2 | 3   | ScriptRepo                           | Script  | /home/omero92/OMERO.server-5.0.6-ice35-b53/lib/scripts
3 | 201 | 105bbfe5-f721-48b5-ba66-6ccf80df8430 | Managed | /home/omero92/ManagedRepository
(4 rows)


ClayB wrote:Yes, the change line is in the Blitz-0.log file:

Code: Select all

2015-05-14 11:11:50,209 WARN  [      o.s.blitz.repo.AbstractRepositoryI] (2-thread-2) Data directory moved: /OMERO/ManagedRepository updated to /home/omero92/ManagedRepository


Hmmm...that's a good sign. It would be good to know if there are any errors before or after that.

Here is the result of the bin/omero fs repos command:

Code: Select all

Created session 3554aea9-c33e-4a04-bdf0-75d8a4fd9de7 (root@localhost:4064). Idle timeout: 10.0 min. Current group: system
# | Id  | UUID                                 | Type    | Path               
---+-----+--------------------------------------+---------+--------------------------------------------------------
0 | 1   | 4f70f5bc-4809-4084-a654-20680c81a140 | Public  | /OMERO             
1 | 2   | 49de94f0-d591-4c1a-a159-4bf0b46cc11f | Public  | /OMERO/ManagedRepository
2 | 3   | ScriptRepo                           | Script  | /home/omero92/OMERO.server-5.0.6-ice35-b53/lib/scripts
3 | 201 | 105bbfe5-f721-48b5-ba66-6ccf80df8430 | Managed | /home/omero92/ManagedRepository
(4 rows)


Which confirms my suspicion. Row #1 is your old repo, which should have been renamed, but instead, row #3 was created. Can you show us the output of:

Code: Select all

psql omero -c "select repo, count(repo) from originalfile where repo in ('49de94f0-d591-4c1a-a159-4bf0b46cc11f', '105bbfe5-f721-48b5-ba66-6ccf80df8430') group by repo;"


I.e. how many files are in each repo? (as far as the DB is concerned). The fix should be fairly straight-forward, but it's best to check the state of things before proceeding. If you'd like to read up on similar issues, see:

• http://lists.openmicroscopy.org.uk/pipermail/ome-users/2014-November/004897.html
• http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2014-October/003020.html
• https://trac.openmicroscopy.org.uk/ome/ticket/12355

Cheers,
~Josh

(I'm not getting notices of updates to this thread, thus my delay in response. Plus, this is a test system for me, so no critical data that others are relying on.)

Here's the results of the 'psql' command with the relevant database name:

Code: Select all

omero92> psql omero92_database -c "select repo, count(repo) from originalfile where repo in ('49de94f0-d591-4c1a-a159-4bf0b46cc11f', '105bbfe5-f721-48b5-ba66-6ccf80df8430') group by repo;"
                 repo                 | count
--------------------------------------+-------
105bbfe5-f721-48b5-ba66-6ccf80df8430 |    22
49de94f0-d591-4c1a-a159-4bf0b46cc11f |   108
(2 rows)



As for counts of files, I've attached files old.txt and new.txt that show the contents of the original ManagedRepository and the list of files in "new" ManagedRepository after it was copied over to the new location (and I had added some test files in the new account). I used the 'du -h' command at the ManagedRepository directory.

Hi Clay,

if this is a safe place to test, I'd suggest updating all files to have just one of the two UUIDs, e.g.

Code: Select all

begin;
update originalfile set repo = '49de94f0-d591-4c1a-a159-4bf0b46cc11f' where report = '105bbfe5-f721-48b5-ba66-6ccf80df8430 ';
commit


and then make sure there is no reference to 105bbfe5-f721-48b5-ba66-6ccf80df8430 remaining in the /OMERO and /OMERO/ManagedRepository metadata directories:

Code: Select all

grep -r 105bbfe5-f721-48b5-ba66-6ccf80df8430  /OMERO/.omero /OMERO/ManagedRepository/.omero
find /OMERO/.omero /OMERO/ManagedRepository/.omero | grep 105bbfe5-f721-48b5-ba66-6ccf80df8430


Cheers,
~Josh.