Re: [Samba] mac client: folder copy problem
Different issue that the winbind one, hopefully will be fixed in a future
update, along with the winbind issue.
George
On Dec 16, 2009, at 9:48 AM, Anton Starikov wrote:
Probably it can be related.
In my case filesync of portable directories with samba server always fail for
newly created directories with error
0:: 09/12/16 06:49:55.282 EXCEPTION: Invalid argument -SStoreFileOperator_FS
applyPermissionsFromObject: (StoreFileOperator-FS.m:508):
chflags('/Network/Servers/samba.server.host/cifstest/', flags=0)-- Error
Domain=NSPOSIXErrorDomain Code=22 UserInfo=0x10058c170 Invalid argument
It tries to chflags after creation of directory and get this error.
Anton.
On Dec 16, 2009, at 6:37 PM, Ryan Suarez wrote:
Volker Lendecke wrote:
On Wed, Dec 16, 2009 at 09:30:18AM -0800, Jeremy Allison wrote:
Yes, I have seen this at a customer site. I've stared at the
logs and sniffs for MANY hours, but I could not find
anything. If you solve this, please let me know :-)
Try pinging George and James (CC:ed on this :-).
Hopefully they can help.
Already done. Jht mentioned that turning off winbind fixed
it for him ... :-)
hmm, this server isn't even running winbind...
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 10:08 AM, Jeremy Allison wrote: On Wed, Dec 16, 2009 at 07:00:09PM +0100, Anton Starikov wrote: And although it creates directory, it doesn't copy contents, because it stops process of copying directory after this error. If I repeat filesync, the contents of directory will be copid (cause directory is already here). So, it looks exactly the same. If so, then problem in chflags(). I expect that samba on linux is compiled without support for chflags, obviously. I presume that settings unix extensions = no would probably fix this, but it has a drawback, because then you loose native unix things like symlinks etc. Which is, at least in our case is not possible, cause shares accessed by both, mac and linux clients over NFS (the same clients on different hosts) and symlinks are heavily used. I think, OSX client, when it sees that server supports unix extensions, expects that on other side is OSX server with samba which supports chflags. So, if we don't discuss rewrite of OSX cifs FS, then only solution is to emulate chflags support on samba side (or convert flags to XFS/ETX3 attrs somehow) Hmmm. Looks like a client bug then, in that they don't cope with an error on chflags set. What error is the Samba server returning here ? George, what errors can the MacOSX client cope with and continue ? Jeremy. The lack of support of the BSD MODES flags in Samba is a known issue that we hope to solve in a future release. We will never be able to support Samba correctly without these bits, but plan on doing a better job in the future.It would be nice if Samba would support the following flags the same as the DOS Attributes. That would solve so many issues:) BSD hidden Flag - DOS Attribute Hidden BSD immutable - Windows Read-Only bit BSD archived - the reverse of the BSD archive bit But the UNIX extensions does not require this support, but this causes the Mac OS Client to have several issue. George -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 10:51 AM, Anton Starikov wrote: Yep, and there is some other problem with OSX client and linux samba server: smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Desktop/ddldldl|755 smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Library/Application Support/Growl/Tickets/.fstemp.+PHD-R-722svsk6Bb5-cifstest+jMHkRwxhxN3.noindex|644 cmsdata smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Library/Application Support/Growl/Tickets/.fstemp.+PHD-R-722svsk6Bb5-cifstest+jMHkRwxhxN3.noindex|744 It is with unix extensions = yes. Please get me more details George On Dec 16, 2009, at 7:08 PM, Jeremy Allison wrote: On Wed, Dec 16, 2009 at 07:00:09PM +0100, Anton Starikov wrote: And although it creates directory, it doesn't copy contents, because it stops process of copying directory after this error. If I repeat filesync, the contents of directory will be copid (cause directory is already here). So, it looks exactly the same. If so, then problem in chflags(). I expect that samba on linux is compiled without support for chflags, obviously. I presume that settings unix extensions = no would probably fix this, but it has a drawback, because then you loose native unix things like symlinks etc. Which is, at least in our case is not possible, cause shares accessed by both, mac and linux clients over NFS (the same clients on different hosts) and symlinks are heavily used. I think, OSX client, when it sees that server supports unix extensions, expects that on other side is OSX server with samba which supports chflags. So, if we don't discuss rewrite of OSX cifs FS, then only solution is to emulate chflags support on samba side (or convert flags to XFS/ETX3 attrs somehow) Hmmm. Looks like a client bug then, in that they don't cope with an error on chflags set. What error is the Samba server returning here ? George, what errors can the MacOSX client cope with and continue ? Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 10:59 AM, Anton Starikov wrote: But what is strange, is the fact that I don't see chflags commands, during audit of server side. And, obviously, client accepts chmod_acl errors silently. (Although I don't have ACL's on files on server side, as result). So, it looks like client knows that server doesn't support chflags, and complains locally. Can it be an issue, that vfs_audit doesn't audit chflags if they unsupported on server side? So with Mac OS the chflags can also be set with getattrlist:( There are several known issue here, we try to work around these issues, but sadly I didn't do a very good enough job handling the lack of support. George On Dec 16, 2009, at 7:51 PM, Anton Starikov wrote: Yep, and there is some other problem with OSX client and linux samba server: smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Desktop/ddldldl|755 smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Library/Application Support/Growl/Tickets/.fstemp.+PHD-R-722svsk6Bb5-cifstest+jMHkRwxhxN3.noindex|644 cmsdata smbd_audit: cifstest|IP_HERE|cifstest|chmod_acl|fail (No data available)|Library/Application Support/Growl/Tickets/.fstemp.+PHD-R-722svsk6Bb5-cifstest+jMHkRwxhxN3.noindex|744 It is with unix extensions = yes. On Dec 16, 2009, at 7:08 PM, Jeremy Allison wrote: On Wed, Dec 16, 2009 at 07:00:09PM +0100, Anton Starikov wrote: And although it creates directory, it doesn't copy contents, because it stops process of copying directory after this error. If I repeat filesync, the contents of directory will be copid (cause directory is already here). So, it looks exactly the same. If so, then problem in chflags(). I expect that samba on linux is compiled without support for chflags, obviously. I presume that settings unix extensions = no would probably fix this, but it has a drawback, because then you loose native unix things like symlinks etc. Which is, at least in our case is not possible, cause shares accessed by both, mac and linux clients over NFS (the same clients on different hosts) and symlinks are heavily used. I think, OSX client, when it sees that server supports unix extensions, expects that on other side is OSX server with samba which supports chflags. So, if we don't discuss rewrite of OSX cifs FS, then only solution is to emulate chflags support on samba side (or convert flags to XFS/ETX3 attrs somehow) Hmmm. Looks like a client bug then, in that they don't cope with an error on chflags set. What error is the Samba server returning here ? George, what errors can the MacOSX client cope with and continue ? Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 1:39 PM, Anton Starikov wrote: On Dec 16, 2009, at 10:28 PM, Ryan Suarez wrote: Anton Starikov wrote: Then with unix extension = yes there os no way for propagation of ACL's? BTW, I tried it with unix extension = no on server side. According to google it used to work on 10.5.x in this way. Nope, I'm testing with OSX v10.5.7 client and we have 'unix extensions=no' explicitly set on the server. This problem still occurs. Then I don't understand. I found few cases on the internet, where disabling of unix extensions helped to enable ACL for 10.5.x. Probably it was with older versions of Leopard with older of smbfs. unix extension on or off has no affect on ACL support. We turn on NT Style ACL support only if we think the Server, Client and Network Log in user all belong to the same Domain. George -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 11:24 PM, Volker Lendecke wrote: On Wed, Dec 16, 2009 at 11:16:24PM -0800, George K Colley wrote: The lack of support of the BSD MODES flags in Samba is a known issue that we hope to solve in a future release. We will never be able to support Samba correctly without these bits, but plan on doing a better job in the future.It would be nice if Samba would support the following flags the same as the DOS Attributes. That would solve so many issues:) BSD hidden Flag - DOS Attribute Hidden BSD immutable - Windows Read-Only bit BSD archived - the reverse of the BSD archive bit But the UNIX extensions does not require this support, but this causes the Mac OS Client to have several issue. Where in the protocol do these show up? In a unixinfo call? If they directly map to the Windows attributes, it should be possible to splice them into our Winattr logic (x permission bits or the EA xattr). Volker So the UNIX INFO2 call both FindFirst and Query have support for these fields. In the Samba Docs at http://wiki.samba.org/index.php/UNIX_Extensions#SET_CIFS_UNIX_INFO. 4 108 ULONG FileFlags File flags enumeration 4 112 ULONG FileFlagsMask Mask of valid flags If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0. The defined set of file flags is File Flag Value Interpretation EXT_SECURE_DELETE 0x0001 File should be erased such that the data is not recoverable EXT_ENABLE_UNDELETE 0x0002 File should opt-in to a server-specific deletion recovery scheme EXT_SYNCHRONOUS 0x0004 I/O to this file should be performed synchronously EXT_IMMUTABLE 0x0008 NO changes can be made to this file EXT_OPEN_APPEND_ONLY0x0010 Only appends can be made to this file EXT_DO_NOT_BACKUP 0x0020 Backup programs should ignore this file EXT_NO_UPDATE_ATIME 0x0040 The server is not required to update the last access time on this file EXT_HIDDEN 0x0080 User interface programs may ignore this file We only care about the EXT_IMMUTABLE, EXT_HIDDEN and EXT_DO_NOT_BACKUP(reverse of the DOS Archive Bit) Set Query UNIX Info2 allow us to set these values. George -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] mac client: folder copy problem
On Dec 16, 2009, at 11:31 PM, Anton Starikov wrote: On Dec 17, 2009, at 8:22 AM, George K Colley wrote: On Dec 16, 2009, at 1:39 PM, Anton Starikov wrote: On Dec 16, 2009, at 10:28 PM, Ryan Suarez wrote: Anton Starikov wrote: Then with unix extension = yes there os no way for propagation of ACL's? BTW, I tried it with unix extension = no on server side. According to google it used to work on 10.5.x in this way. Nope, I'm testing with OSX v10.5.7 client and we have 'unix extensions=no' explicitly set on the server. This problem still occurs. Then I don't understand. I found few cases on the internet, where disabling of unix extensions helped to enable ACL for 10.5.x. Probably it was with older versions of Leopard with older of smbfs. unix extension on or off has no affect on ACL support. We turn on NT Style ACL support only if we think the Server, Client and Network Log in user all belong to the same Domain. How to check it or enforce it? Setup is next: 1) On OSX 10.5 server OpenDirectory + samba PDC. ON 10.5 we require that the mount point be owned by an AD user and the log user is an AD user. 2) Linux server with samba (member of domain hosted on OSX) Can't be some with 10.5 clients 3) OSX 10.6 client. OSX client login as OpenDirectory user. In opendirectory apple-user-homeurl set to point to samba share on linux server. Need to return the correct info in the WhoAMI call. I will need to look at the code. So let me get back to you on this one. George Anton. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
