Re: SAMBA/CIFS error
ugh - figured it out...
background, sambaserver was originally resolving to 192.168.1.101 which was also servicing NCP.
login script command:
#net use H: \\sambaserver\data\shared\officeA\shared\
mapping works.
changed sambaserver to resolve to 192.168.1.102 which was responding to SMB/CIFS only (no NCP)
#net use H: \\sambaserver\data\shared\officeA\shared\
mapping failed.
Correct mapping:
#net use H: \\sambaserver\data\shared\officeA\shared
got rid of last backslash and it works.
Apparently the backslash at the end of the net use command is fine if NCP takes over and maps it under Novell protocols without issues. Switch over net use to CIFS/SMB and it fails under the Microsoft protocols unless the last backslash is removed.
oy.
>>> On 5/19/2009 at 5:11 PM, David Poole<Dpoole@prmc.com> wrote:
Ran into the strangest problem:
1) have two contexts in my eDir tree. Let's call them ContextA and ContextB.
2) users are LUM-enabled, universal passwords and Samba-enabled
3) have a Samba share called DATA on a NSS volume
4) have a directory structure on the DATA share:
\\sambaserver\data\shared\officeA\users
\\sambaserver\data\shared\officeA\shared
-and-
\\sambaserver\data\shared\officeB\users
\\sambaserver\data\shared\officeB\shared
5) for both \officeA\users\ and \officeB\users\ there are folders that represent the individual home directories of my users - rights granted via NSS to the users for their home directories.
6) for both \officeA\shared\ and \officeB\shared\ there are a series of folders inside the \shared\ folder, such as \marketing\ and \common\ and \administration\
users do NOT have access via NSS to the \shared\ folder directly, but thru eDirectory group memberships, groups are granted rights to the \marketing\, \common\ and \administration\ folders inside the \shared\ folder if the user needs access to those folders.
Now for the kick in the pants:
1) users from ContextB can log in and using NET USE in the login scripts, get drives mapped to their home directories and to the \shared\ folder (to see the folders below they have access to, I am mapping directly to \shared\).
so far so good...
but:
2) users from ContextA can log in and using NET USE in the login scripts, get drives mapped to their home directories BUT NOT to the \shared\ folder (to see the folders below they have access to). I get an error 67 "The network name cannot be found"
However, if I were to map to a folder inside \shared\ (such as \shared\common\) that they have access to via NET USE, it works fine.
It SHOULD work like ContextB as described above but it does not. I've searched high and low and cannot find any setting associated to ContextA that would limit their drive mappings via SMB (NET USE) that would account for this. Can anyone tell me why NET USE works one way for ContextA users and another way for ContextB users even though everything else (user rights, folder assignments, etc) appear to be identical!?!?!?
I'll be sitting here banging my head against the table...
|