Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
You are right - when i tried the unix extensions off earlier, I'd amended smb.conf in the section that related to the specific share. I moved the "unix extensions = no" entry into the [global] section of smb.conf, restarted samba and everything works well. Phew and thanks!

Of course, since the server is mine to control and setup, this fix is OK - not sure if campus wide servers would be amenable to such a change.

VMT

Bob

Glad I could help...

A comment....
Not sure if we can blame MAC OS here. This as MAC OS probably try to use features Samba announces it has. It is probably a faulty Samba config as "unix extensions" feature is quite complex. BUT.... I think unix extensions should be turned off by default in Samba as it was from the very beginning.... _IF_ you turn it on, it should be because you need it and then you probably spend the time to understand and configure it correct.

If you have bought a NAS with a Samba implementation where you cannot change this unix extensions and it's turned on by default or not configurable, well.... then I think the NAS should be returned as faulty...


Over and out...

/Per-Olov
 
Found "a" solution to the NAS/SMB write problem in OS X 10.6.3

Normally I only troll forums like this for advice and answers to my own problems and typically find the answers to my questions so it is rare that ever actually have anything worthwhile to contribute in the form of a solution, but...

I to have been having a problem writing to my Taurus GIGA LAN NAS ever since I upgraded to Snow Leopard 10.6.3. I had no trouble with the NAS under 10.6.2, but after the upgrade, I could no longer write files to the SMB shares I had set up on the NAS, shares that had been fine before the upgrade to 10.6.3.

After reading the posts in this thread, I noticed that the extended attributes--denoted by the "@" in the "ls -al" attribute listing for a given file--were my problem as well.

Before trying any of the samba.conf modifications described in the various posts, I decided to see if, perhaps, there were any known issues with my NAS. I had also been having a problem with it when copying large numbers of files at once to/from the unit. It occurred to me that a Firmware upgrade may be in order, so I happened upon this page:

http://www.inxtron.com/resources/firmware/tauruslan

Note: Keep in mind that this solution applies, specifically, to this make/model of NAS (though a similar solution may work for other makes and models).

I upgraded to the "v2.6.3-20091215S" firmware since, as I mentioned above, the "Latest changes" section interested me:

"Fixed: SMB server stops responding after copying a large amount of files all at once (approx. 50000 files or more)"

After upgrading the firmware to this new version according to the instructions in my owners manual--although the instruction on the page itself are very good as well--my write problems, extended attributes or no--had disappeared.

I agree with pos that it is probably not all Apple's fault on this one. I have used Samba off and on for years in various Linux ventures with a number of different distributions and kernels and found that there's always something not quite in synch. The fact that, after all the posts I read concerning the various tweaks and workarounds surrounding the samba.conf file and then to find out that a simple firmware upgrade solved my problems... well, it seems that pos may be right in that Apple's implementation is only attempting to capitalize on services that Samba is billed as having... at least in the latest versions.

Obviously, with many NAS units, direct manipulation of the samba.conf file (or whatever it's equivalent is for the unit) isn't possible, so the firmware upgrade was my only option. I can only assume that this, effectively upgraded the Samba server on the NAS to a point where it was again compatible with the options associated with Apple's implementation in 10.6.3.
 
Same issue here. "Fortunately", my NAS drive also supports AppleTalk, so I can bypass the problem by using AFP instead of SMB. Neither protocol works well with Mac, but SMB is the lesser of two evils. With SMB, browsing the drive is fast, but copying large numbers of files takes forever. With AFP, copying huge numbers of files works OK but browsing is very laggy.

I gotta say, since switching to Mac about a year ago I'm getting seriously bothered by the amount of stuff that keeps breaking in these updates. Say what you will about Windows service packs, but in my experience they never introduced weird random bugs like these OS X updates do. Networking seems to be a particularly dodgy part of OS X...
 
Per Olov you saved the day!!


After 1 hour of stress from customers who updated to 10.6.3 you 'saved my day' :)

This solution works for me.. and i am sure it's a bug.


Well. Than you have a fault installation/config of Samba.

Also. Please explain why "root" should own the files????? You are not root in MAC OS? Beware that root or the admin user in Samba config is a VERY special user. If I remember it right, everything that is written by a samba admin will be owned by root. Don't config anything as samba admins or root.
I have a share with:
[gem]
comment = Gemensamma filer
path = /data/gem
valid users = +gem, +gemadm, +gemwri
read list = +gem
write list = +gemadm, +gemwri
admin users = +gemadm
force group = gem
create mask = 0660
directory mask = 0770
force create mode = 0660
security mask = 0770


And if I go back to the basics and look at files I OWN the directory I want to create files in. No matter wheter you look at the directory in Linux or under /Volumes/<MYSHARE> in Mac. Also, I am a member of the needed groups. DO I have to tell you it worked just before upgrade to 10.6.3 as well?


/Per-Olov
 
FIXED: Easy solution

You don't need to turn off Unix extensions on your Samba server at all, that may well do loads of things you didn't want. Here we *have* to have the Unix extensions switched on, as our Linux clients all use CIFS.

I have written a very simple workaround for the problem which is here:
http://www.jules.fm/Logbook/files/cant_copy_mac_to_samba.html

That works fine for me, and doesn't involve any changes to your SAMBA or NAS server at all.

Let me know if you find it useful!
 
Confirmation...

Just confirm, I've experienced the same issue where a user (10.6.3 and fully updated Office 2008) cannot copy/move files to a samba share on a bsd server.

Removing the extensions on the file seems to work:

1) xattr -v filename (to list the extensions)
2) xattr -d extension filename (to remove)

However, this may be difficult for the end user to do all the time. The other option, turning off unix extensions in the server side smb.conf may break other linux machines...

Is there not a way to save Office 2008 files without the extensions? That may prove to be the easiest solution...
 
anyone having trouble with external drives connected with firewire 800?

I'm getting the "this operation can't be completed because the item " " is in use" error when I try to copy to my external hard drive. plus, when this happens the whole system sort of freezes, forcing me to crash restart it :(

is anyone having similar problems? I'm having this problem both with versions 10.6.4 and 10.6.5

I tried formatting the disk (which is in mac journaled) and keep getting the same problem. formating to fat32 seems to work but I work with media files way bigger than 4GBs so no solution there...

help? anyone?? please??

thank you!!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.