Is it using the proper domain designation? Just something I thought I would throw out there. Since the manual selections worked, I didn't know if you script might be missing something.

go to the local area connection properties on the xp box and go to the authentication tab and uncheck "use authentication control IEEE 802" or some sh!t like that

Thank you both for your replies... Sorry so long for the delay in my own follow-up... my exams this week have preoccupied me.
 
Clutch:
-------
The exact "mount" that I'm using is as follows:
 
mount -w -t smbfs -o username=ccjones,password=<<censored>>,dmask=0744,fmask=0744,workgroup=OLYMPUS //cthulu/d$ /data/cthulu-d
 
Where the workstation that the server is trying to mount, obviously, is "cthulu", and the workgroup (no domain controller exists, only a workgroup designation) is "OLYMPUS". I get the error:
 
6792: tree connect failed: ERRDOS - ERRnoaccess (Access denied.)
SMB connection failed
 
However... if I explicitly share the d: volume on the workstation as "drive-d" and substitute "//cthulu/drive-d" for the "//cthulu/d$", it actually works. On the XP workstation, I can look in Computer Management console and see the existence of the d$ share, and even connect to it locally (as if going through the network) by typing "\\cthulu\d$" as the address in an explorer window. Bizarre. The explicit share will work, but I would prefer to use the hidden administrative share if at all possible (as I did with Win2000).
 
If nothing else, it is cool being able to SSH into my server from work and obtain these details
 
Four and Twenty:
----------------
I'm going to try changing that property as soon as I get home. Thanks for the suggestion!

No luck with the "IEEE 802.1" option... Disabled it, and still got the "Not Authorized" error... Damn.

You can connect via script to another share correct? Then try making another hidden share using the "$" (like reidyn$) and see if you scripting contiues to have errors. It could perceive the "$" as either an illegal character for sharing, or as another command and/or variable.

I think clutch is on the right track..... I wonder, can you escape the '$'? i.e., enter the path as "//cthulu/d\$".... something to try anyway

It continues to be interesting. I created an invisible share (an entire drive, actually) by appending the "$" after the share (e.g., "reidyn$"), and successfully connected to that share with the expected rights on the Linux server.
 
I also tried "escaping" the "$" in "C$" by substituting a "\$" for the "$".... no luck connecting to the administrative share.
 
Also, for S&G, tried both uppercase and lowercase on the "C$" just in case it had become a case-sensitivity issue with Linux... no luck.
 
I have noticed that in Windows XP, UNLIKE Windows 2000 and NT, explicitly sharing any resource causes a lengthy attribute change of some sort (which I haven't identified WHAT exactly), rather than just quickly creating the share as in earlier OSes. The higher the level being shared (i.e., the more files and folders beneath), the longer it takes. Don't know whether this has a connection... It would be interesting to try to connect to the Windows XP C$ share from a Windows 2000 or NT machine to see whether they can do it, or whether the fact that I can connect back to my own machine from the same machine is because XP is uniquely equipped for whatever changes have taken place.
 
To p!ss me off even more, I can't even get a good search on Google or Deja... the "$" is dropped from the search criteria, and I can't figure a way to retain it.

It gets more interesting yet....
 
Playing with SMBCLIENT and observing the connection with Computer Management on XP, I can see that even when I log in from SAMBA with the same ID that has admin priveledge on the XP box, it still connects as a separate ID (since the server is the machine that is connecting) and also shows as "guest".
 
If I remove the "everyone" share, and only add my actual ID to have sharing priveledges, then I can't get access from SAMBA even though I'm connecting with that same ID... So unlike 2000 and NT, which would both assume that if you use the same ID you're trying to log in under the same account, this one actually assumes that the same ID on a different box is NOT the same as the local. Now I can't figure how to force it to use the same.
 
Interesting change of authentication. I have tried sending the ID as "xpboxname/username", and "xpboxname\\username" ... no luck. Tried forcing the netBIOS name to be the same as the XP box name, and still can't fool it. Damn it.
 
The temporary solution, I suppose, is to add "\\sambaservername\username" to my XP box's user accounts. I hate that, as I still don't get the C$ and D$ admin shares.
 
There HAS to be an answer. I can't quite figure whether this indicates that SAMBA needs to catch up, or a setting in XP.

I had the same problem trying to access the admin share even though I
had a local account.
 
Here is what has to be changed:
 
I figured out how to share with login/admin rights as well as remove the <ctrl>
right click junk to bring up the share option...
 
What you need to do is:
1- bring up the local security policy (in admin tools)
2- under security settings -> Local policies -> Security options look for and
change:
a- "do not allow anonymous enumeraation of SAM accounts" it should be Disabled
b- "do not allow anonymous enumeraation of SAM accounts and shares" it should
be Disabled.
c- "force network logons using local accounts to authenticate as Guest" should
be disabled.

Sorry it took so long... I've been away. This worked BEAUTIFULLY. The only change is that in the local security policy, the #4 item to change has been renamed in RC-2 as:
 
"Sharing and security model for local accounts", which should be changed to "Classic - Local users authenticate as themselves"
 
EXCELLENT work in finding this. I have successfully mounted my administrative shares to my Linux server and deleted the dangerous "everyone" invisible shares.