LawIS
asked on
Error accessing new Server 2003 shares from iSeries AS400 v5r4...
I administer a network containing both Windows and AS400 servers. We are attempting to establish a connection so that files output by the AS400 are dumped on a 2003 server. Long established shares are accessible from the AS400, but any new share set up will only allow the AS400 to view, not write or delete. For example:
\\server\oldfolder (local windows path of "d:\oldfolder") has existed for years and is fully accessible from the AS400.
\\server\newfolder (local windows path of "d:\newfolder") was created today and can only be read from the AS400.
The strange thing is, a new folder created within the old folder such as "d:\oldfolder\subfolder" will be accessible through the old share \\server\oldfolder\subfold er, but inaccessible from a dedicated new share with the path \\server\subfolder. This rules out permissions from the windows side as the culprit, as all permissions are NTFS and no restrictions are set on the share itself.
Neither myself or the AS400 administrator are very versed in the intercommunication of our systems, but it appears the common denominator is time. Is it possible that there is some process that needs to occur to make these new shares write accessible to the AS400? We have tried deleting the linking directory in QNTC on the AS400 and recreating it, but with no change.
\\server\oldfolder (local windows path of "d:\oldfolder") has existed for years and is fully accessible from the AS400.
\\server\newfolder (local windows path of "d:\newfolder") was created today and can only be read from the AS400.
The strange thing is, a new folder created within the old folder such as "d:\oldfolder\subfolder" will be accessible through the old share \\server\oldfolder\subfold
Neither myself or the AS400 administrator are very versed in the intercommunication of our systems, but it appears the common denominator is time. Is it possible that there is some process that needs to occur to make these new shares write accessible to the AS400? We have tried deleting the linking directory in QNTC on the AS400 and recreating it, but with no change.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Do I have this correct?
1) Is WINS configured and used by QNTC, or do you manually add servers to QNTC using MD?
2) Does a Windows user, logged on a different system from the machine hosting the shares, and using the same profile as the AS/400 user experience the same problem?
- Gary Patterson
- Old share: d:\oldfolder shared as OLDFOLDER, FULL ACCESS
- New share: d:\newfolder shared as NEWFOLDER, READ-ONLY
- New subdir in old shared folder: OLDFOLDER\newsubfolder, FULL ACCESS
- New share of new subdir: d:\oldfolder\newfolder2 shared as NEWFOLDER2, NO ACCESS (or READ oNLY?)
- Share permissions on each share Everyone with FULL CONTROL, all others removed. (Remember that 2003 defaults new shares to READ ONLY, unlike older versions of Windows.)
- NTFS permissions one each directory show Everyone with FULL CONTROL, all other removed.
1) Is WINS configured and used by QNTC, or do you manually add servers to QNTC using MD?
2) Does a Windows user, logged on a different system from the machine hosting the shares, and using the same profile as the AS/400 user experience the same problem?
- Gary Patterson
ASKER
Yeah, your summation is dead on. Servers were manually added using MD, and windows users were having no problem writing to the share from the windows environment, BUT....
It is now working.
Not quite a full 24 hours since the new share was created, and after confirmed read-only access right before I went home last night, the share can now be written from the AS/400.
I'm not sure if this is related, but I had also tested some user-rights behavior. If the user is removed entirely or if rights are restricted on the windows side there is at least a 15 minute delay of the user being logged off before the user is denied access.
Thanks for your help!
It is now working.
Not quite a full 24 hours since the new share was created, and after confirmed read-only access right before I went home last night, the share can now be written from the AS/400.
I'm not sure if this is related, but I had also tested some user-rights behavior. If the user is removed entirely or if rights are restricted on the windows side there is at least a 15 minute delay of the user being logged off before the user is denied access.
Thanks for your help!
Share permissions are stored in the registry on the server that hosts the share. I don't know what might cause a delay like the one you are seeing there, other than a bug. Are you current on 2003 service packs and fixes? Sounds like windows or AS/400 perhaps cached the read-only permissions that were generated by default when the share was changed, or something. Haven't seen that before.
Post back if you come across an answer (or maybe a another expert knows why).
As to the changes in user permissions taking some time to apply, this is normal in a multi-server environment, especially in a multi-location, multi-server network due to Active Directory replication delays (15 minutes isn't unusual).
It is possible to force Active Directory Replication:
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/ActiveDirectory/ForcingActiveDirectoryReplication.html
- Gary Patterson
Post back if you come across an answer (or maybe a another expert knows why).
As to the changes in user permissions taking some time to apply, this is normal in a multi-server environment, especially in a multi-location, multi-server network due to Active Directory replication delays (15 minutes isn't unusual).
It is possible to force Active Directory Replication:
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/ActiveDirectory/ForcingActiveDirectoryReplication.html
- Gary Patterson
ASKER
I will attempt to get some captures of the working and non-working actions, as well as double check the security logs. Thanks for the suggestions, I'll post back when I get a chance to check things out a little farther.