проблемы с login script и подключением сетевых дисков

[pavlika]

Есть два дерева: X (nw 5.0.1) и Y (nw 5.0.7) тома традиционные, за исключением SYS на Y. 'Избранные' пользователи дерева X цепляют диски из Y через TREE TREE_NAME/COMPLETE_NAME и MAP ... . В один прекрасный день, диски мапиться перестали, но пользователи через сетевое окружение на ресурс заходят. Если логинимся только в дерево Y, то заходим без отработки LOGIN SCRIPT, и таже фигня по поводу доступности сетевых ресурсов: только через сетевое окружение. При попытке посмотреть свойства томов через Nwadmin ругается. При входе admin_ом (LOGIN SCRIPTа нет) входим только на том SYS, остальные только видим.
Вопрос: что тут можно поделать? (VREPAIR говорит, что все ОК)

P.S.
Посмотрел TID10013948 (Login script is not mapping one volume correctly and comes up with an error). Совет:
(Verify backup is performed before taking these actions)
1. Delete the volume object in NWADMIN32 and re-create it.
2. Run a VREPAIR to make sure the volume is OK.
(This action may take a long time and should be done on off hours)
3. To re-create the volume object you can use DSREPAIR under Check Volume Objects
and Trustees or under INSTALL Volume Options. The action can also be performed
through nwconfig (NW5) or install (NW4.11) Directory options / upgrade mounted
volumes into the directory
не порадовал, т.к. по 'политическим причинам' backup_ов не делалось.

[Сергей ака godless]

Всё таки про DSREPAIR не зря тебе сказали .... Прогони на серверах у себя и посмотри что скажет ....
Что кстати с синхронизацией ??
И потом - просто "в один прекрасны момент" так не бывает, что то явно произошло ... Сбой по питанию допустим или ребут несанкционированный или замена железа .... Так что было то ??

[pavlika]

Запустил UNATTENDED FULL REPAIR на сервере где лежит реплика X, утиль нашла 14 ошибок (на Y все было и раньше ОК). После этого все стало чики-пуки. В связи с этим вопрос (от незнания): что из нижеперечисленного могло быть причиной случившегося и как завязаны между собой два дерева (X и Y), если каждое живет своей жизнью и своим временем (в смысле TIMESYNC TYPE = SINGLE).

P.S.

/****************************************************************************/
NetWare 5.00 Directory Services Repair 7.23 , DS 8.51
Log file for server ".FS.TEST" in tree "TREE_TEST"

** Automated Repair Mode **
Repairing Local Database
Start: Friday, 24 September 2004 11:31:21 Local Time

Structure and Index Check
Creating Temporary Files
Repair Trees - Scan Values
Repair Trees - Sorting Values
Repair Trees - Scan Entries
Repair Trees - Sorting Entries
Repair Trees - Check Values
Repair Trees - Check Entries
Total Objects in Database: 2195
Total Objects in Schema : 909
Total External References: 1
Total Objects in Replicas: 1112
Schema Check

Repairing objects in a replica
Start: Friday, 24 September 2004 11:31:40 Local Time
[1 of 1] Master : T=TREE_TEST
ERROR: Modification time was incorrect, it has been updated
Object ID: 00008313, DN: CN=tamplate_dmo.OU=DMO.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 00008327, DN: CN=1upr.OU=DMO.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 0000832A, DN: CN=rukovod.OU=DMO.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 000089A2, DN: CN=all_users_DMO.OU=DMO.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 00008426, DN: CN=user_template_omu.OU=OMU.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 00008427, DN: CN=1otdel.OU=OMU.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 0000848A, DN: CN=template_uns.OU=UNS.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 00008491, DN: CN=allusers.OU=UNS.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 00008492, DN: CN=ssn.OU=UNS.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 000086EF, DN: CN=k506.OU=UNS.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 0000891C, DN: CN=common.OU=UNS.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 000084D2, DN: CN=template_upo.OU=UPO.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 000087D8, DN: CN=USER_TEMPLATE_USR.OU=USR.O=TEST.T=TREE_TEST

ERROR: Modification time was incorrect, it has been updated
Object ID: 000088D3, DN: CN=user_template_sek.OU=SEKRETARIAT.O=TEST.T=TREE_TEST

Total Objects = 1112, UNKNOWN class objects = 0, Total Values = 47674
Creating Old Files
Temporary DIB set replaced NDS working DIB set.
Checking mail directories
Checking stream syntax files
Repair process completed, total errors found = 14
Finish: Friday, 24 September 2004 11:32:07 Local Time
Total repair time: 0:00:46

** Automated Repair Mode **
Repairing Server Network Addresses
...
далее все ОК

Насколько моя глупая голова понимает что-то где-то со временем!?

[Сергей ака godless]

Всё нижесказанное - ИМХО ...

Деревья у тебя живут в разных временах, скорее всего получилось расхождение и в результате какое то действие над объектом одного дерева случилось раньше времени на другом дереве ... Делали это всё юзвери которые непонятно откуда вообще берут синхронизацию ...
Так что сверять время, а лучше прицепить синхронизацию одного сервера к другому и к атомарнику и не мучать голову ....
Ну или оба к атомарнику зацепить, это на вкус уже ....

[pavlika]

Спасибо! Подумаем, почитаем. Меня только немножко, совсем чуть-чуть, смущает то, что такая ерунда произошла в первый раз, а дерево Y живет 4 месяца.
Еще раз спасибо, пойдем грызть гранит науки.

[pavlika]

Гранит грызем видно плохо, т.к. проблема осталась, правда видоизменилась. Вчера пользователи снова перестали цеплять сетевые диски из дерева Y. При попытке выполнить map root J:=\\server\volume\folder говорит, что не находит volume, причем не важно в какое дерево логинимся, т.е. и пользователи для которых дерево Y родное ничего не цепляют. Сегодня же утром все подключаются номально (пока). Из внешне заметного упал Long Term Cache Hits до 45%.
???

[Сергей ака godless]

Гранит грызем видно плохо, т.к. проблема осталась, правда видоизменилась. Вчера пользователи снова перестали цеплять сетевые диски из дерева Y. При попытке выполнить map root J:=\\server\volume\folder говорит, что не находит volume, причем не важно в какое дерево логинимся, т.е. и пользователи для которых дерево Y родное ничего не цепляют. Сегодня же утром все подключаются номально (пока). Из внешне заметного упал Long Term Cache Hits до 45%.
???

Я бы на твоём месте удалил из дерева объект этого тома и из консоли восстановил его ... Вот только не знаю как в этом случае с правами будет на том ...
Ну и конечно же посмотреть helth самого тома, вдруг он у тебя отключился ??