Hello, I am running latest version of NexentaStor v1.1.7, and I have experienced an ongoing issue where access to CIFS shares from Windows is failing intermittently. I found the source of the problem during my testing yesterday. Share access was failing from 1:32pm until 1:45:55pm. I noticed that when I ran 'dmesg', I kept seeing idmap failures for Administrator.
Here is output from /var/adm/messages: Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change global_catalog=dev-vmfrdc1.liquor.dev port=3268 Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change global_catalog=dev-vmbwdc1.bourbon.liquor.dev port=3268 Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change global_catalog=dev-vmbstopdc1.bstop.liquor.dev port=3268 Apr 13 20:21:46 dev-cask idmap[298]: [ID 452674 daemon.info] change domains_in_forest=liquor.dev Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change trusted_domains=scotch.liquor.dev direction=bi-directional Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change trusted_domains=bourbon.liquor.dev direction=bi-directional Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change trusted_domains=bstop.liquor.dev direction=bi-directional Apr 13 20:23:46 dev-cask smbd[1140]: [ID 775558 daemon.debug] smb_door_srv_func: execute server routine(opcode=0) Apr 13 20:23:46 dev-cask smbd[1140]: [ID 395423 daemon.debug] smbrdr_ntcreatex: 18 \netlogon Apr 13 20:23:47 dev-cask smbd[1140]: [ID 528497 daemon.debug] SmbRdrNtCreate: fid=16388 Apr 13 20:23:47 dev-cask idmap[298]: [ID 821686 daemon.debug] Using global catalog server dev-vmbstopdc1.bstop.liquor.dev:3268 Apr 13 20:23:47 dev-cask smbd[1140]: [ID 702911 daemon.debug] [0] ^H\226^N^H\310\227^N^H-513 (-9976) Apr 13 20:23:47 dev-cask smbd[1140]: [ID 266262 daemon.error] BOURBON\Administrator: idmap failed Share access was restored immediately after I ran the command: # svcadm refresh idmap Currently, the only Windows DC accessible to Nexenta box (dev-cask) is DEV-VMBWDC1.bourbon.liquor.dev -- both are in the same domain. So it appears these timeouts are caused by Nexenta (OpenSolaris) trying to get to an alternate DC (DEV-VMBSTOP1.bstop.liquor.dev) which is unreachable because it is on a different subnet, on a different domain. Since it can't get there, the id mappings fail, and hence the share access fails. Why is the Nexenta box trying to use a DC that's outside of its own domain? Why does it need to get to all DCs? The only servers that can talk to all DCs currently are the DCs themselves. Do I need to open up communication to all DCs for the Nexenta box? ----------------------------------------- Please consider the environment before printing this e-mail CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at (440) 788-5000, and delete the original message immediately. Thank you. _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
