imkdir status = -814000 CAT_UNKNOWN

d hu

unread,

Jun 20, 2018, 2:38:17 PM6/20/18

to iRODS-Chat

Hi,

Need some help on irods. We are running 4.2.2 and all the following command was on irods CAT server with "irods" admin privilege.

_irods@irodsa:~$ icd;ipwd

/resarchivezone/home/irods

running as admin, we used to be able to create shared group folders under /resarchivezone/, such as:

_irods@irodsa:~$ ils -L /resarchivezone/ccm

/resarchivezone/ccm:

C- /resarchivezone/ccm/dhutest

But now I could not create any new folders under /resarchivezone/, see below for error message,

_irods@irodsa:~$ imkdir /resarchivezone/testfolder001

remote addresses: 127.0.1.1 ERROR: mkdirUtil: mkColl of /resarchivezone/testfolder001 error. status = -814000 CAT_UNKNOWN_COLLECTION

Level 0: collection '/resarchivezone' is unknown

_irods@irodsa:~$

I suspect some config might be changed in the environment but not sure how to fix this. tried ichmod to change but with no luck.

Thanks,

Dong

Terrell Russell

unread,

Jun 21, 2018, 8:58:06 AM6/21/18

to irod...@googlegroups.com

Hi Dong,

Can you share what else is under the top level?

ils -AL /resarchivezone/

I just tried, and it seemed to work as expected...

$ ienv | grep version

irods_version - 4.2.3

$ icd;ipwd

/tempZone/home/rods

$ imkdir /tempZone/mytestcoll

$ ils -AL /tempZone

/tempZone:

ACL - rods#tempZone:own

Inheritance - Disabled

C- /tempZone/home

C- /tempZone/mytestcoll

C- /tempZone/trash

Terrell

--
--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org

iROD-Chat: http://groups.google.com/group/iROD-Chat

---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

d hu

unread,

Oct 2, 2018, 3:30:23 PM10/2/18

to iRODS-Chat

We upgraded to 4.2.3 and restarted all servers and still have this problem.

==

_irods@irodsa:~$ ils -AL /resarchivezone/

remote addresses: 127.0.1.1 ERROR: lsUtil: srcPath /resarchivezone does not exist or user lacks access permission

_irods@irodsa:~$ imkdir /resarchivezone/testfolder001

remote addresses: 127.0.1.1 ERROR: mkdirUtil: mkColl of /resarchivezone/testfolder001 error. status = -814000 CAT_UNKNOWN_COLLECTION

Level 0: collection '/resarchivezone' is unknown

==

We had this working at the beginning and started to have this problem a couple months ago. There must be something changed but we could not figure out what and how to fix it.

The following are the folders we created before we had this problem, from the "create_ts" we had the last folder created on April 10th.

ICAT=# select * from r_coll_main where parent_coll_name='/resarchivezone';

----------+------------------+------------------------------+-----------------+-----------------+-------------+------------------+-----------+------------+------------+----------------+-----------+-------------+-------------

3932475 | /resarchivezone | /resarchivezone/ahuang_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931450 | 01527088143

3932482 | /resarchivezone | /resarchivezone/andrew_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931511 | 01527088149

3932461 | /resarchivezone | /resarchivezone/arnold_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931048 | 01527088155

3127723 | /resarchivezone | /resarchivezone/ashlien_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060658 | 01527088161

3675715 | /resarchivezone | /resarchivezone/ccm | irods | resarchivezone | 0 | 1 | | | | | | 01512748708 | 01512748858

3932468 | /resarchivezone | /resarchivezone/ciruna_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931299 | 01527088173

3127724 | /resarchivezone | /resarchivezone/davidm_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060671 | 01527088184

3495535 | /resarchivezone | /resarchivezone/dirkslab_grp | irods | resarchivezone | 0 | 1 | | | | | | 01510246000 | 01527088184

10006 | /resarchivezone | /resarchivezone/home | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

3840372 | /resarchivezone | /resarchivezone/lhiraki_grp | irods | resarchivezone | 0 | 1 | | | | | | 01518621247 | 01527088213

3932448 | /resarchivezone | /resarchivezone/mdtaylor_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519928903 | 01527088213

3932489 | /resarchivezone | /resarchivezone/mdwilson_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931837 | 01527088213

12866937 | /resarchivezone | /resarchivezone/mice_grp | irods | resarchivezone | 0 | 1 | | | | | | 01523373253 | 01527088213

3127725 | /resarchivezone | /resarchivezone/pray_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060691 | 01527088213

5380130 | /resarchivezone | /resarchivezone/smital_grp | irods | resarchivezone | 0 | 1 | | | | | | 01520279038 | 01527088128

19004 | /resarchivezone | /resarchivezone/tcag | irods | resarchivezone | 0 | 1 | | | | | | 01503603753 | 01503690161

10047933 | /resarchivezone | /resarchivezone/testtcag_grp | irods | resarchivezone | 0 | 1 | | | | | | 01521051402 | 01527088213

10007 | /resarchivezone | /resarchivezone/trash | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

(18 rows)

One possible cause of this problem could be we tried to update ICAT db with sql directly to "chown" some files. Is it possible that this operation accidentally changed some setting in database? How can we debug to find out?

If any more info you want to check please let me know.

Thanks,

Dong

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.

dmoore.renci

unread,

Oct 2, 2018, 4:54:55 PM10/2/18

to iRODS-Chat

hello Dong,

When you did the SQL update, did you by chance mean to tag the coll_owner_name columns for those collections as 'rods', instead of 'irods'? On many / most systems, 'rods' is the admin account while 'irods' is the name service account (login name for doing irods administration.)

I am coming into this exchange pretty fresh, mind you, but could you send me the output of the command below, executed as iRODS admin:

iquest "select USER_NAME"

This will tell you what users are registered in the ICAT database, and therefore also whether the name of the collections owner in the raw SQL should actually be 'rods' or 'irods'.

Just a hunch, but it could pay off :)

-Dan

////

Daniel Moore - Applications Engineer - iRODS Consortium

RENCI

UNC Chapel Hill

d hu

unread,

Oct 3, 2018, 3:39:35 PM10/3/18

to iRODS-Chat

Thanks for looking into our problem.

The output you asked,

==

_irods@irodsa:~$ iquest "select USER_NAME"|grep rod

USER_NAME = rodsadmin

USER_NAME = irods

==

I guess when irods inital set up, we chose to use "irods" instead of "rods" as admin id.

The sql command we used to update ownership is something like "update r_data_main set data_owner_name='donghu' where data_path='/asresc/home/stephen/test.txt';" and we only tested updating a few lines so don't see how this could cause the problem to "imkdir" at the top level.

Thanks,

Dong

dmoore.renci

unread,

Oct 4, 2018, 2:56:19 PM10/4/18

to iRODS-Chat

Dong,

Perhaps you could do an 'ils -L' on one of the data objects in the affected storage resource and make sure the permissions on all directories in the hierarchy have octal '7' (read + write + execute) permissions set for the service account user? (Judging from your shell prompt, this appears to be "_irods" rather than the usual "irods", but correct me if I am mistaken)

-Dan

d hu

unread,

Oct 9, 2018, 1:35:35 PM10/9/18

to iRODS-Chat

If you meant to check the unix file system permissions on each resource node, it seems fine. And yes, the unix id for irods admin is "_irods" in our environment.

Thanks,

21: drwxr-xr-x 18 _irods _irods 336 Oct 3 16:33 /asresc

22: drwxr-xr-x 16 _irods _irods 292 Oct 3 16:33 /asresc

23: drwxr-xr-x 15 _irods _irods 268 Oct 3 16:33 /asresc

24: drwxr-xr-x 16 _irods _irods 290 Oct 3 16:33 /asresc

25: drwxr-xr-x 16 _irods _irods 293 Jun 22 16:35 /asresc

26: drwxr-xr-x 17 _irods _irods 312 Oct 3 16:33 /asresc

27: drwxr-xr-x 11 _irods _irods 179 Oct 3 17:53 /asresc

28: drwxr-xr-x 17 _irods _irods 310 Oct 3 16:33 /asresc

41: drwxr-xr-x 15 _irods _irods 294 Oct 3 15:33 /asresc

42: drwxr-xr-x 16 _irods _irods 290 Oct 3 15:33 /asresc

43: drwxr-xr-x 14 _irods _irods 250 Oct 3 15:33 /asresc

44: drwxr-xr-x 17 _irods _irods 318 Oct 3 16:33 /asresc

45: drwxr-xr-x 14 _irods _irods 260 Jun 22 16:36 /asresc

46: drwxr-xr-x 18 _irods _irods 334 Oct 3 16:18 /asresc

47: drwxr-xr-x 14 _irods _irods 260 Jun 22 16:35 /asresc

48: drwxr-xr-x 18 _irods _irods 334 Sep 5 08:39 /asresc

dmoore.renci

unread,

Oct 10, 2018, 6:22:12 PM10/10/18

to iRODS-Chat

hi Dong

Sorry to take a while getting back to you on this .... I will try to reproduce this on a 4.2.2 tomorrow. But at present, I can't think of why it would be happening.

Is it possible the root collection object for the zone was somehow altered in the ICAT, perhaps even via raw SQL? You may particularly want to look at the value of the coll_owner_name column.

-Dan

d hu

unread,

Oct 11, 2018, 2:48:01 PM10/11/18

to iRODS-Chat

Thanks for your update.

I did a search for coll_owner_name is irods, and noticed some "/mresarchivezone" and "/m", wondering if this could be wrong?

Thanks,

Dong

ICAT=# select * from r_coll_main where coll_owner_name='irods';

----------+----------------------------------+---------------------------------------------+-----------------+-----------------+-------------+------------------+-----------+------------+------------+----------------+-----------+-------------+-------------

12866937 | /resarchivezone | /resarchivezone/mice_grp | irods | resarchivezone | 0 | 1 | | | | | | 01523373253 | 01527088213

13585070 | /resarchivezone/home/irods | /resarchivezone/home/irods/testfolder001 | irods | resarchivezone | 0 | | | | | | | 01524768525 | 01524768525

3932475 | /resarchivezone | /resarchivezone/ahuang_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931450 | 01527088143

3932461 | /resarchivezone | /resarchivezone/arnold_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931048 | 01527088155

3932468 | /resarchivezone | /resarchivezone/ciruna_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931299 | 01527088173

3127724 | /resarchivezone | /resarchivezone/davidm_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060671 | 01527088184

3127725 | /resarchivezone | /resarchivezone/pray_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060691 | 01527088213

14868520 | /resarchivezone/trash/home/irods | /resarchivezone/trash/home/irods/smital_grp | irods | resarchivezone | 0 | | | | | | | 01527088455 | 01527088455

10004 | /m | /m | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01528912251

21404492 | /resarchivezone/home/irods | /resarchivezone/home/irods/testfolder01 | irods | resarchivezone | 0 | | | | | | | 01531852625 | 01531852625

21404496 | /resarchivezone/home/irods | /resarchivezone/home/irods/testfolder02 | irods | resarchivezone | 0 | | | | | | | 01531852626 | 01531852626

21404503 | /resarchivezone/home/irods | /resarchivezone/home/irods/testfolder03 | irods | resarchivezone | 0 | | | | | | | 01531852630 | 01531852630

17645323 | /resarchivezone/home/irods | /resarchivezone/home/irods/f001 | irods | resarchivezone | 0 | | | | | | | 01529518098 | 01529518098

17645336 | /resarchivezone/home/irods | /resarchivezone/home/irods/f002 | irods | resarchivezone | 0 | | | | | | | 01529518100 | 01529518100

17649151 | /resarchivezone/ccm | /resarchivezone/ccm/f01 | irods | resarchivezone | 0 | 1 | | | | | | 01529518575 | 01529518575

17672160 | /resarchivezone/home/irods | /resarchivezone/home/irods/tf001 | irods | resarchivezone | 0 | | | | | | | 01529522268 | 01529522268

17672169 | /resarchivezone/home/irods | /resarchivezone/home/irods/tf002 | irods | resarchivezone | 0 | | | | | | | 01529522270 | 01529522270

3675715 | /resarchivezone | /resarchivezone/ccm | irods | resarchivezone | 0 | 1 | | | | | | 01512748708 | 01538669122

3495535 | /resarchivezone | /resarchivezone/dirkslab_grp | irods | resarchivezone | 0 | 1 | | | | | | 01510246000 | 01527088184

3840372 | /resarchivezone | /resarchivezone/lhiraki_grp | irods | resarchivezone | 0 | 1 | | | | | | 01518621247 | 01527088213

3932448 | /resarchivezone | /resarchivezone/mdtaylor_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519928903 | 01527088213

10006 | /resarchivezone | /resarchivezone/home | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

10007 | /resarchivezone | /resarchivezone/trash | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

10008 | /resarchivezone/trash | /resarchivezone/trash/home | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

10009 | /resarchivezone/home | /resarchivezone/home/public | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

10010 | /resarchivezone/trash/home | /resarchivezone/trash/home/public | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

10005 | /m | /mresarchivezone | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

19004 | /resarchivezone | /resarchivezone/tcag | irods | resarchivezone | 0 | 1 | | | | | | 01503603753 | 01503690161

3675671 | /resarchivezone/home | /resarchivezone/home/ccm_grp | irods | resarchivezone | 0 | | | | | | | 01512747674 | 01512747674

10011 | /resarchivezone/home | /resarchivezone/home/irods | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503506900

10012 | /resarchivezone/trash/home | /resarchivezone/trash/home/irods | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503506900

3932482 | /resarchivezone | /resarchivezone/andrew_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931511 | 01527088149

3127723 | /resarchivezone | /resarchivezone/ashlien_grp | irods | resarchivezone | 0 | 1 | | | | | | 01507060658 | 01527088161

3932489 | /resarchivezone | /resarchivezone/mdwilson_grp | irods | resarchivezone | 0 | 1 | | | | | | 01519931837 | 01527088213

10047933 | /resarchivezone | /resarchivezone/testtcag_grp | irods | resarchivezone | 0 | 1 | | | | | | 01521051402 | 01527088213

3934167 | /resarchivezone/tcag | /resarchivezone/tcag/ArchiveC | irods | resarchivezone | 0 | 1 | | | | | | 01520007252 | 01520007252

5380130 | /resarchivezone | /resarchivezone/smital_grp | irods | resarchivezone | 0 | 1 | | | | | | 01520279038 | 01527088128

(37 rows)

Daniel Moore

unread,

Oct 11, 2018, 8:09:59 PM10/11/18

to irod...@googlegroups.com

Dong,

Sorry, still in slo-mo here. Internet is down for me. (Using my phone now! ) Anyway, those seem like they couldn't be correct ... perhaps typos resulting from an SQL update? Will ask in the office tomorrow!

Dan

dmoore.renci

unread,

Oct 13, 2018, 1:29:03 PM10/13/18

to iRODS-Chat

hi Dong

It's worrisome that the query on collections owned by irods didn't turn up /resarchivezone (parent = /) and the empty collection itself , "/", which should be its own parent. That could be a reason for not being able to create a subcollection at that level. I'm also guessing that the '/m' objects could be artifacts deliberately created by a database manipulation sometime in the past. Perhaps an admin wished to preserve the irods collection objects but, in the meantime, get them out of the way for some lost purpose we can only guess at. (If true, then they meant to re-use or dispose of them later, but never did.)

By the way, I'm working on how to prescribe a method for you, through de- (and re-) registration, to move the ownership of a tree of files from one user to another. The caveat , they'd have to *both* be rodsadmin users. If that's not acceptable, then the only other way I know to confer ownership to various different users and/or groups -- other than via raw SQL, which is dangerous -- is through ichmod, using iRODS ACL's (Access Control Lists).

- Dan

On Thursday, October 11, 2018 at 8:09:59 PM UTC-4, dmoore wrote:

Dong,
Sorry, still in slo-mo here. Internet is down for me. (Using my phone now! ) Anyway, those seem like they couldn't be correct ... perhaps typos resulting from an SQL update? Will ask in the office tomorrow!
Dan

dmoore.renci

unread,

Oct 13, 2018, 8:44:02 PM10/13/18

to iRODS-Chat

Dong,

A few more thoughts based on my earlier "diagnosis" ( repeated below) ... it is just possible if you use the raw SQL updates necessary to delete the leading 'm's from the two collection objects: you might find yourself again able to create subcollections directly below /resarchivezone :

10004 | /m | /m | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01528912251

10005 | /m | /mresarchivezone | irods | resarchivezone | 0 | | | | | | | 01503330810 | 01503330810

(no guarantees obviously, because using raw SQL on ICAT is playing with fire, and here we are pretty much "fighting fire with fire" :) )

Smeele, A.P.M. (Ton)

unread,

Oct 15, 2018, 2:54:05 AM10/15/18

to irod...@googlegroups.com

Hi Dong,

You may want to try the following sql query:

ICAT=# select * from r_coll_main where coll_name='/';

If that query doesn't show up *any* results then probably your root collection has by some cause been renamed to '/m'.

In that case you could manually update coll_id 10004 and coll_id 10005 to change the fields containing '/m' to '/' using the following:

update r_coll_main set coll_name = '/' where coll_id = 10004;

update r_coll_main set coll_parent_name = '/' where coll_id = 10004 or coll_id = 10005;

Be careful not to update any other rows.

Cheers,

Ton

Daniel Moore

unread,

Oct 15, 2018, 8:27:17 AM10/15/18

to irod...@googlegroups.com

Ton,indeed you are right. Best to make sure that "/" doesn't exist first... regardless of ownership ... before renaming another collection to coincide with it! Thanks - D.M.

d hu

unread,

Oct 16, 2018, 4:13:13 PM10/16/18

to irod...@googlegroups.com

Can confirm there is no coll_name '/':

==

ICAT=# select * from r_coll_main where coll_name='/';

---------+------------------+-----------+-----------------+-----------------+-------------+------------------+-----------+------------+------------+----------------+-----------+-----------+-----------

(0 rows)

==

So we should try update '/m' -> '/' as suggested in id 10004 and 10005, how about the one coll_name = '/mresarchivezone'? should this be updated as '/resarchivezone'?

Thanks,

Dong

You received this message because you are subscribed to a topic in the Google Groups "iRODS-Chat" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/irod-chat/lZeE4AZxE0I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to irod-chat+...@googlegroups.com.

Ton Smeele

unread,

Oct 16, 2018, 6:10:04 PM10/16/18

to irod...@googlegroups.com

You're right Dong, I missed that detail on 10005. So you would need a third SQL statement to update coll_name = '/mresarchivezone' to '/resarchivezone' for that single row.

Pls let us know if that fixed the issue.

Cheers Ton

-----Original Message-----

Date: Tue, 16 Oct 2018 16:12:59 -0400

Subject: Re: [iROD-Chat:17702] Re: imkdir status = -814000 CAT_UNKNOWN_COLLECTION

To: irod...@googlegroups.com

Reply-to: <irod...@googlegroups.com>

From: d hu <don...@gmail.com>

--

d hu

unread,

Oct 17, 2018, 11:48:35 AM10/17/18

to iRODS-Chat

Good news. After updated roll 10004/10005 by removing the "m"s and the problem is fixed. New folders can be created under /resarchivezone/ again.

Those entries could be updated by accident when we try to change some file ownership through sql. It would be great that a i-command be implemented to do this. Currently we have to copy files with new ID to get the ownership / quota changed.

Thanks,

Dong

Daniel Moore

unread,

Oct 17, 2018, 11:57:14 AM10/17/18

to irod...@googlegroups.com

Dong, yes I think so, if you've verified there's presently no existing /resarchivezone

Terrell Russell

unread,

Oct 17, 2018, 11:16:56 PM10/17/18

to irod...@googlegroups.com

Dong,

We have an open issue regarding the 'original owner' and quota counting:

https://github.com/irods/irods/issues/1992

Please share your use case there.

We have done some recent work on quotas and this may be very timely.

https://github.com/irods/irods/issues/4089

Glad your database is back in working order.

Thanks,

Terrell

Reply all

Reply to author

Forward