How do I connect a Powerbook to a WinXP share with read/write access?

February 21, 2005 4:37 PM

I'm trying to figure out how to convince my Powerbook to connect to a WinXP share (that part works) and then have write access to the resulting share.

Here's the situation: I've got an OS X 10.3.8 Powerbook that's connecting to a share on a WinXP Pro desktop. The Powerbook connects to the XP machine with no problem, and it correctly mounts the share I select. The share I've created for the purposes of troubleshooting this problem has absolutely no protections on it in XP. Indeed, I can read from the share without a hitch, but as soon as I try to delete or create a file or folder, I receive a "Permission denied" error from the command line or, through the Finder, a friendly "The operation could not be completed because you do not have enough access privileges" error.

Google says that error crops up in other contexts, which leads me to believe it's a problem on the Mac, but I can't decide if it is, in fact, an OS X problem or something wonky on my XP box. Google-fu has so far produced little useful information beyond this. Thanks, as always, in advance.

posted by socratic to computers & internet (12 comments total)

tried this?
posted by nj_subgenius at 5:00 PM on February 21, 2005

Yup. :)
posted by socratic at 5:10 PM on February 21, 2005

mount -t smbfs //server/share /mnt/directory

has worked for me... but then so did the Aqua "connect to server" thing eventually.

Does the XP box have a user with the same uname as you're using on the mac?
posted by pompomtom at 5:25 PM on February 21, 2005

simple file sharing sucks (imho). turn it off (open Explorer window, go to Folder Options, then uncheck it under the View tab). then, right-click on your share and go to Sharing and Security. ensure the permissions on the share itself are set properly (Sharing tab). then, ensure the permissions on the directory are set properly (Security tab). the dealie is that the filesystem security settings override whatever share permissions you give it - if you give permission to write to the share, but that user doesn't have write permission on the folder itself, you'll get a permission denied error. (sometimes these errors are easier to debug with simple file sharing turned off.) if you've already done this then ignore me. :-)

I've not had any problems connecting to NT workstations during the course of my day (all the stuff I work on is stored on Windows Server 2003 Ent/Std, some 2k Adv, some XP, with auth by AD - my Mac is even in the forest, which is tres cool) but I've heard of some weird problems like that.. you may want to, as a last resort, check your /etc/smb.conf file - if the "encrypt passwords" setting is set to No or missing it may do odd things (i.e. fail authentication but secretly log you in as guest, which probably doesn't have write permission). the only other thing I could think of is maybe having a weird character in the path name - like a forward-slash or a colon or whathaveyou. jooc, did you recently upgrade from 10.3.7, and if so did it work then?
posted by mrg at 5:29 PM on February 21, 2005

I do this a lot, here's my steps:
1) Find the IP address of the windows machine using ipconfig.
2) Right click on the folder I want to share, click "Sharing and Security," click the "Share this Folder" then also click (this is important and might be your problem) "Allow other users to make changes." (The wording might be slightly different.)
3) OSX: Finder->Go->Connect to server: smb://ip.address/. When it asks for username/password, use your XP login.
posted by neustile at 6:38 PM on February 21, 2005

neustile - that's exactly what I was doing, and the problem was still there (like I said, the share is wide open).

I think mrg is on target, but I can't test it just yet.
posted by socratic at 6:57 PM on February 21, 2005

Windows sharing just works for me. I've got a mac with all the updates installed, and a fairly fresh install of WinXP home. It is important to enable "network users to change my files". You may want to right-click and go to preferences and ensure that the underlying filesystem is read-write as well.

With gigabit ethernet on both machines, it is actually faster to copy from mac to the PC than it is mac->mac.
posted by b1tr0t at 7:15 PM on February 21, 2005

I'm going to give mrg the cookie, though b1tr0t gets an honorable mention. It was the damn simple file sharing. I cut it off (I have no idea why it was on, but it's a relatively new XP install), enabled full control for the guest account (on the shared folder ONLY), and now I'm happily copying some Jeff Buckley to the XP box.

Thanks to those who responded!
posted by socratic at 7:19 PM on February 21, 2005

dumb idea: windows sharing has two sets of permissions involved with sharing. The NTFS filesystem permissions and the share permissions. The problem may be the share permissions. The default for the share permissions is read-only. This may be biting you.
posted by jumpsuit_boy at 9:44 PM on February 21, 2005

Follow-up: Is there any way to get shares that are on your desktop to stay mounted after the Mac or the PC are rebooted?
posted by smackfu at 9:35 AM on February 23, 2005

smackfu -

i can't give a full response right now, but check this:

AFP Automount with a login script will do the trick mac-wise.

All of this works (generally) a-okay for me, altho I occasionally need to reboot either of the machines to get rid of a silly -43 samba error.
posted by ArcAm at 10:24 AM on February 23, 2005

smackfu - write an AppleScript. fire up Script Editor, do this: "tell application finder \n mount volume "smb://myserver/stuff" \n end tell" (\n means press Enter), then save it as an Application (not a Script) and put it in your Startup Items in the Accounts preference pane. be advised that the Finder does not mount subdirectories in shares (i.e. \\server\share\someotherdirectory doesn't work) - it'll mount the root (\\server\share\) and if you try to do that multiple times you'll get an error message.

thanks for the cookie :)
posted by mrg at 3:26 PM on February 26, 2005