RE: Mac to PC file sharing issues on SBS2003
From: Jim Sykora (JimSykora_at_discussions.microsoft.com)
Date: 12/28/04
- Next message: James B: "Re: Problem with popup message"
- Previous message: James B: "Re: VPN Logon"
- In reply to: Eriq Neale [MSFT]: "RE: Mac to PC file sharing issues on SBS2003"
- Next in thread: Eriq Neale: "Re: Mac to PC file sharing issues on SBS2003"
- Reply: Eriq Neale: "Re: Mac to PC file sharing issues on SBS2003"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 28 Dec 2004 10:05:01 -0800
Eriq:
I've done all the steps that you outlined in your response below. I have
disabled the Client for Macintosh Services(AFP) portion of the share, moved
my "data" share out of the Microsoft UAM folder and am running a purely SMB
solution now as the OS 9.x clients will be getting upgraded to OSX shortly.
I've changed some file permisions and have everything set to Everyone: Full
Control for both the share permissions and the security permissions on the
"data" share, which has taken care of any problems I was having with not
being able to rename folders.
I don't seem to get any problems with not being able to access folders from
the server or PC clients anymore after moving everything out of the Microsoft
UAM Volume share.
I do still have one problem, however. Every once in a while, at seemingly
random intervals I have problems with the Mac clients not properly closing
out the resource forks of the files. This usually isn't a big deal, and
we've not experienced any data loss from it. I am able to just go to the
server management and close the mysteriously open resource forks. The
problem comes in when the end user wants to move a folder or set of files.
If the resource fork is still open on the server for no reason they will get
a username and password prompt on their Mac when they try to move the folder
and then it will still tell them "access is denied, you do not have
permission". If you go to the server and close the ._ resource fork file
that is open for no reason then the file will move properly with no problems.
If the resource fork is open for a single file inside of a folder then that
entire folder is pretty much dead to the world, except for that the Mac that
originated the connection can still open that specific data file. If you
reboot the Mac the resource fork still remains open, and seems to remain open
for quite a while, but it does close at some point by itself so there is a
time-out period definately. You can manually close the resource fork ._ file
on the server or you can reboot the server. Also note that the Mac clients
are running 10.3.7 now also.
Have any ideas on this one? I noticed that other people are having similar
problems with this issue in one of your links you gave me, and I also noticed
that someone was having problems with the Mac clients mysteriously keeping
random resource forks open on Linux Samba servers as well, so it would
definately seem that this isn't a Microsoft issue...
Thanks in advance.
"Eriq Neale [MSFT]" wrote:
> > From: "=?Utf-8?B?SmltIFN5a29yYQ==?=" <Jim
> Sykora@discussions.microsoft.com>
> >
> > I am working with a small printing company that does desktop publishing
> as a
> > majority of their business model. They use PCs for most of their
> workflow,
> > but for the desktop publishing they uses Macs running OSX 10.3. I have
> set
> > up a Small Business Server 2003 at their site. I have all of their PCs
> > connected to the SBS server flawlessly. I have all 4 of their Macs
> connected
> > to the SBS server via SMB and have them logging into the domain as
> members.
> > I have resolved all of the DNS issues with .local addresses, and I have
> > disbabled SMB digital signing on the server. Everything works with the
> Macs
> > connecting to the SMB shares on the SBS2003 server the majority of the
> time.
> > However, I am having 3 problems that I cannot find any resolution to that
> > I've listed below. I have posted on private newsgroups also and I intend
> to
> > contact Mac technical support as well, but am looking for any insight
> from
> > this community as well.
>
> Hey Jim. Responses inline below.
>
> > Problems:
> > 1) Originally I had both SMB shares and Client for Macintosh Services
> > enabled as possibilities as they had 1 OS 9.2 Mac that they would have
> liked
> > to connect to the server via UAM. When using Client for Macintosh
> services
> > and the Microsoft UAM on the Mac clients I experienced odd problems with
> > Quark Express files for the Mac OS10.3 clients loosing their association
> with
> > the Quark program. If I renamed
> > the file on a PC to have a Quark extension, and then opened the file in
> > Quark on the PC workstation and saved it as a Mac Quark document then the
> Mac
> > workstation was able to open it. Once I disabled the UAM volume share in
> > Manage Computer I no longer experienced this issue now that I am using a
> > standard SMB share. I have heard of people loosing files when using SMB
> as
> > oposed to AFP, but I have not, as of yet, expierienced this. Any ideas
> on
> > this?
>
> Quark is a strange bird when it comes to shared network storage. If you
> haven't checked out any of the Quark support forums, I would suggest that
> you do.
>
> The issue of Appletalk vs. SMB is how the files are stored on the server.
> When you make an AppleTalk connection to the Windows server and save Mac
> files on the server, the files are stored in native Mac file format, i.e.,
> the resource fork is stored within the body of the file. That resource fork
> data is then only accessible by Macs who connect through Appletalk shares.
> If you access that file from a PC, make changes, and save it back out, only
> the data fork is saved and the resource fork is gone. That causes problems
> when a Mac tries to access the file later.
>
> When you connect via SMB, you are saving files in Windows native file
> format, which does not understand resource fork/data fork formats on the
> Mac. The Macs recognize this and only save the data fork information,
> relying on other methods to maintain the information that is normally saved
> in the resource fork (such as application association being handled by file
> extension instead of file type/creator info in the resource fork).
> Specifically, Mac OS X will create a second file on the shared folder that
> contains the resource fork information. This second file is not seen by
> Macs that access the SMB share, but will sometimes show up in a Windows
> Explorer view of the same shared folder. You can read more about this in
> this Apple article: http://docs.info.apple.com/article.html?artnum=106510.
> There's also an active discussion on the Apple boards about issues related
> to this that you might find interesting:
> http://discussions.info.apple.com/webx?128@221.nqCUafkWtXp.0@.68947f81.
>
>
> > 2) Mac clients are able to rename files, but not containing folders in
> the
> > share, even when made a user of the Domain Admins group(for testing
> > purposes). The Mac clients recieve access denied messages. This happens
> > with every folder created on the Mac OS10.3 client.
>
> I think I can address this issue with questions/comments for the next item.
>
> > 3) There are several folders that I cannot access from a PC that are
> still
> > accesable from the Mac clients. When I try to access them from the
> server I
> > get the
> > message: "C:\Micorosft UAM Volume\Data\Tanya\92470 Prevailing Winds NL
> Dec.
> > refers to a location that is unavailable. It could be on a hard drive on
> > this computer, or on a network. Check to make sure that the disk is
> properly
> > inserted, or that you are connected to the Internet or your network, and
> then
> > try again. If it
> > still cannot be located, the information might have been moved to a
> > different location." If I browse to this directory from the Mac client
> it
> > shows up normally as one would expect. This does not happen for every
> > folder. So far it has happened for 3 out of 25 folders on the share.
>
> If I'm reading this correctly, you are trying to use the Microsoft UAM
> Share as a data share for the Macs to access. That's not the purpose of
> that share. The Microsoft UAM Share is intended to be a read-only share
> that Mac OS 8&9 clients can access to download and install the UAM client
> so they can connect to the server with improved authentication. What you
> really need to do is to create new Mac data shares and assign them
> permissions appropriately. Take a look at this article
> (http://simultaneouspancakes.com/Int/archive/2004/08/connecting_a_ma_2.shtml
> ) to learn more about configuring SBS 2003 to let Macs connect via
> AppleTalk.
>
>
> > If anyone has any suggestions to resolving any of these issues, or if
> more
> > information is needed please let me know.
>
> Hope this helps.
>
> -Eriq
> ----------------------
> Eriq Neale - MCSE 2003, MCSA Messaging, MCP Small and Medium Business
> Microsoft Corporation
>
> Get Secure! - http://www.microsoft.com/security
>
> =====================================================
> When responding to posts, please "Reply to Group" via
> your newsreader so that others may learn and benefit
> from your issue.
>
> For SBS 4.5 issues, post to: microsoft.public.backoffice.smallbiz
> For SBS 2000 issues, post to: microsoft.public.backoffice.smallbiz2000
> For SBS 2003 issues, post to: microsoft.public.windows.server.sbs
> =====================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
- Next message: James B: "Re: Problem with popup message"
- Previous message: James B: "Re: VPN Logon"
- In reply to: Eriq Neale [MSFT]: "RE: Mac to PC file sharing issues on SBS2003"
- Next in thread: Eriq Neale: "Re: Mac to PC file sharing issues on SBS2003"
- Reply: Eriq Neale: "Re: Mac to PC file sharing issues on SBS2003"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
