Koozali.org: home of the SME Server

Indesign/Incopy permission problems on ibay shares

Offline judgej

  • *
  • 375
  • +0/-0
Indesign/Incopy permission problems on ibay shares
« on: April 02, 2008, 06:55:45 PM »
We are having problems with sticky-bits mysteriously disappearing from some i-bay folders.

We are using Indesign on a couple of Macs (OS-X), with Incopy used to write 'assignments' to shared i-bays. An assignment consists of a folder and some files, which another user accesses using 'Incopy' on their PC. All Macs have Appletalk turned off, so we are using Samba for everything.

We are finding that occasionally, a folder created by a Mac sometimes lacks the 'sticky bit' on the group permissions. This causes problems with ownership on all the files that get placed within it (i.e. the group of all files created within the folder belong to the file owner, and not the i-bay, so no other i-bay users can write to those files, or even to the folder).

First question: is it even possible for the sticky bit of a folder to be reset through a Samba connection?

If so, then how can we avoid it? If not, then are we encountering a known Samba bug?

Anyone seen anything like this before?

Just so this is a little clearer, we have an i-bay folder like this:

.../ibayname/files: drwxrwsr-x ibayname ibayname

Normally if a folder is created in that ibay, the permissions would be:

.../ibayname/files/mydir: drwxrwsr-x myuser ibayname

Then any files created within that folder would get a group of 'ibayname'.

When it goes wrong, the folder created looks like this:

.../ibayname/files/mydir: drwxrw-r-x myuser myuser

That means only the user that created the folder can write inside the folder. This does not consistently happen, just occasionally, and we are not sure what is significant about those occasions.
« Last Edit: April 02, 2008, 07:01:08 PM by judgej »
-- Jason

Offline pfloor

  • ****
  • 889
  • +1/-0
Re: Indesign/Incopy permission problems on ibay shares
« Reply #1 on: April 02, 2008, 07:00:31 PM »
Could be Apple, Samba, SME or the program itself.  However, you know what type of answer you are going to get here.

"Take it to the bug tracker with precise details and let the Devs determine where the bug lies."
In life, you must either "Push, Pull or Get out of the way!"

Offline judgej

  • *
  • 375
  • +0/-0
Re: Indesign/Incopy permission problems on ibay shares
« Reply #2 on: April 02, 2008, 07:01:40 PM »
I'll take it to the bug tracker after I have talked to the community with the day-to-day use experience. That's not to say the devs don't have the experience, but I'm not ready to bother them yet.

I'll take the bugs to the devs after that. Sorry - that's just the way I am ;-)
« Last Edit: April 02, 2008, 07:05:47 PM by judgej »
-- Jason

Offline judgej

  • *
  • 375
  • +0/-0
Re: an update (a bug, and a fix)
« Reply #3 on: April 03, 2008, 01:55:01 PM »
I have a suspicion this is related to a Samba bug/setting that is coming to light over a number of sites. Samba 3.0 basically does not like Mac OS X Leopard. We do not have this problem with older versions of OS X. For example, this looks very similar:

http://www.afp548.com/forum/viewtopic.php?showtopic=19291

So OS X Leopard may be changing privileges on folders it creates via a Samba link - but I am still confused as to how it is managing to do this, i.e. why SME Server is allowing it (unless it really is a Samba bug).

-----------------

Update to the update: we have diagnosed the problem and found a workaround:

Samba 3.0.2x (we are using 3.0.28) has the 'unix exptensions' option set to 'on' by default. This allows Unix users who write to the Samba shares to set their own permissions bits. Mac OS X up until now has never attempted to do this, but from Leopard, any directory that gets created on a Samba share, get chmod'ed through this Samba extension. That really screws up the i-bay files since users must *not* change these permissions - the sticky bit is very important in order for i-bays to work the way they do.

The workaround (and ultimately the permantent solution) is to set the following in smb.conf:

unix extensions = no

Restart samba, and the problem goes away.

Bug raised here: http://bugs.contribs.org/show_bug.cgi?id=4164
« Last Edit: April 03, 2008, 04:33:57 PM by judgej »
-- Jason