RE: [Samba] Problem with Excel on a share with ACLs
> -Original Message- > From: Martin Konold [mailto:[EMAIL PROTECTED] > > Also, do you have a default ACL set > > on the directory? > > No. All files in the directory have very different ACLs. What > would the default ACL be good for? It wouldn't do any good, in that case. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Problem with Excel on a share with ACLs
Am Montag, 20. September 2004 15:24 schrieb David Brodbeck: Hi David, > I don't follow; if the user belongs to a group that has read/write access, > they should be able to modify anything except the file permission bits. Yes, this is exactly the to be expected behavior. Unfortunately this does _not_ work. What happens is that if user B opens the file F with Excel 97, modifies it and then tries to save the file the following happens: Excel does not directly write to file F on der Samba server but it creates an intermediate file called something like E04FF34. Immediately after the completion of this write Excel renames this intermediate file to the real filename. The difference with Samba and a W2K server is that W2K _preserves_ the original owner/group/ACLs of the destination file. > Also, do you have a default ACL set > on the directory? No. All files in the directory have very different ACLs. What would the default ACL be good for? > This relies on Samba knowing what exactly the program on the user's > computer is intending to do. I don't think there's any way of identifying > this. Remember that these two steps may be several minutes or even several > hours apart, and there's no reliable way for Samba to tell Excel apart from > any other program. From my traces it looks like W2K uses some heuristic as the renaming is immediately after the completion of the write and the source has these strange intermediate filenames. IMHO because W2K can it Samba should also be technically able to handle it. Yours, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
RE: [Samba] Problem with Excel on a share with ACLs
> -Original Message- > From: Martin Konold [mailto:[EMAIL PROTECTED] > I am experiencing the problem as described in > http://us1.samba.org/samba/docs/man/Samba-Guide/kerberos.html# > id2562652 > > Unfortunately the remedy/workaround as described there does > not work in the more general case of ACLs. > > Problem description: > - User A owns file F. > - User B has rw access to F via a user ACL > - Group G has rw access to F via a group ACL > - User B edits the excel file F > - User B saves file F. > - File F gets stored with user B being the owner and with read-only > permissions (this behaviour is specific to samba/excel and > does not happen with a W2K server) > - Due the concept of effective ACLs the file cannot be > modified by user A > anymore even though that user A belongs to the supplementary > group B which has > rw access I don't follow; if the user belongs to a group that has read/write access, they should be able to modify anything except the file permission bits. Could you clarify what the problem is? Also, do you have a default ACL set on the directory? > it would be better if samba would do the following > - create new file intermediate file > - "cat" contents of the intermediate file on the _existing_ file This relies on Samba knowing what exactly the program on the user's computer is intending to do. I don't think there's any way of identifying this. Remember that these two steps may be several minutes or even several hours apart, and there's no reliable way for Samba to tell Excel apart from any other program. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
