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
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 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 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 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: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
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 17, 2009, at 8:35 AM, George K Colley wrote: >>> 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. There is no AD. OSX server acts as PDC. But in smb.conf on this server it is pointed that profiles and homes should be taken from linux server (for windows clients domain logons). We mount nothing on 10.5 server itself. it just acts as authorization center for all kind of services. On linux file-server, obviously, home shares are same user home directories we share over NFS. So, permissions are OK. >> 2) Linux server with samba (member of domain hosted on OSX) > Can't be some with 10.5 clients Didn't get your point here. >> 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. OK, I'll test it today. Anton. -- 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 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. 2) Linux server with samba (member of domain hosted on OSX) 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. Anton. -- 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 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 signature.asc Description: Digital signature -- 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: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. Anton. -- 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
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. -- 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:13 PM, James Peach wrote: > > It doesn't use unix ACLs, it uses SMB ACLs. 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. But on 10.6.2 it results in the same behavior: chmod: Failed to set ACL on file '/tmp/qq1/tt1': Operation not supported Anton. -- 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
2009/12/16 Anton Starikov : > > On Dec 16, 2009, at 9:45 PM, James Peach wrote: > >> 2009/12/16 Anton Starikov : >>> One question. >>> >>> The fact that client ignore ACL capabilities of server, it is also normal >>> for current smbfs implementation? >> >> Even in 10.5, the smbfs client does not ignore the filesystem ACL >> support attribute. > > With unix extensions enabled? > > Then I don't understand. Where is the problem. > > On server side I see > > smbd_audit: antst|xxx|antst|sys_acl_get_file|ok|. > smbd_audit: antst|xxx|antst|sys_acl_get_file|ok|. > smbd_audit: antst|xxx|antst|sys_acl_get_entry|ok| > smbd_audit: antst|xxx|antst|sys_acl_free_acl|ok| > smbd_audit: antst|xxx|antst|sys_acl_free_acl|ok| > smbd_audit: antst|xxx|antst|get_nt_acl|ok|. > > > a file: > > # getfacl /home/antst/tt1 > getfacl: Removing leading '/' from absolute path names > # file: home/antst/tt1 > # owner: antst > # group: cmsusers > user::rw- > user:mohand:rwx > group::r-- > mask::rwx > other::--- > > And on client side: > > ls -le /tmp/qq1/tt1 > -rw-r- 1 antst cmsusers 0 Dec 16 20:19 /tmp/qq1/tt1 > > > And if I try to set ACL from OSX I get > $ chmod +a "mohand allow write" /tmp/qq1/tt1 > chmod: Failed to set ACL on file '/tmp/qq1/tt1': Operation not supported > > Looking into the source code of client (thanks for link) I see that > CIFS_UNIX_POSIX_ACLS_CAP is not referenced in the sources (except header > file, where it is defined). Although it can mean nothing and you can use > somewhere in the code just numerical value. It doesn't use unix ACLs, it uses SMB ACLs. -- James Peach | jor...@gmail.com -- 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 9:45 PM, James Peach wrote: > 2009/12/16 Anton Starikov : >> One question. >> >> The fact that client ignore ACL capabilities of server, it is also normal >> for current smbfs implementation? > > Even in 10.5, the smbfs client does not ignore the filesystem ACL > support attribute. With unix extensions enabled? Then I don't understand. Where is the problem. On server side I see smbd_audit: antst|xxx|antst|sys_acl_get_file|ok|. smbd_audit: antst|xxx|antst|sys_acl_get_file|ok|. smbd_audit: antst|xxx|antst|sys_acl_get_entry|ok| smbd_audit: antst|xxx|antst|sys_acl_free_acl|ok| smbd_audit: antst|xxx|antst|sys_acl_free_acl|ok| smbd_audit: antst|xxx|antst|get_nt_acl|ok|. a file: # getfacl /home/antst/tt1 getfacl: Removing leading '/' from absolute path names # file: home/antst/tt1 # owner: antst # group: cmsusers user::rw- user:mohand:rwx group::r-- mask::rwx other::--- And on client side: ls -le /tmp/qq1/tt1 -rw-r- 1 antst cmsusers 0 Dec 16 20:19 /tmp/qq1/tt1 And if I try to set ACL from OSX I get $ chmod +a "mohand allow write" /tmp/qq1/tt1 chmod: Failed to set ACL on file '/tmp/qq1/tt1': Operation not supported Looking into the source code of client (thanks for link) I see that CIFS_UNIX_POSIX_ACLS_CAP is not referenced in the sources (except header file, where it is defined). Although it can mean nothing and you can use somewhere in the code just numerical value. Anton -- 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
2009/12/16 Anton Starikov : > One question. > > The fact that client ignore ACL capabilities of server, it is also normal for > current smbfs implementation? Even in 10.5, the smbfs client does not ignore the filesystem ACL support attribute. > > On Dec 16, 2009, at 9:28 PM, James Peach wrote: > >> 2009/12/16 Jeremy Allison : >>> 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 ? >> >> FileSync wants to create accurate copies of files, including all their >> metadata. We just pass the error up the stack. The current code does >> not look too closely at the unix capabilities, we should be looking >> at the flags mask in the UNIX_INFO2 response and handling the case >> where the server doesn't understand any flags. >> >> Please file a bug at http://bugreporter.apple.com and attach the >> packet trace. This will help us to make a case to fix this in an >> update. >> >> -- >> James Peach | jor...@gmail.com > > -- James Peach | jor...@gmail.com -- 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
One question. The fact that client ignore ACL capabilities of server, it is also normal for current smbfs implementation? On Dec 16, 2009, at 9:28 PM, James Peach wrote: > 2009/12/16 Jeremy Allison : >> 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 ? > > FileSync wants to create accurate copies of files, including all their > metadata. We just pass the error up the stack. The current code does > not look too closely at the unix capabilities, we should be looking > at the flags mask in the UNIX_INFO2 response and handling the case > where the server doesn't understand any flags. > > Please file a bug at http://bugreporter.apple.com and attach the > packet trace. This will help us to make a case to fix this in an > update. > > -- > James Peach | jor...@gmail.com -- 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 9:28 PM, James Peach wrote: > Please file a bug at http://bugreporter.apple.com and attach the > packet trace. This will help us to make a case to fix this in an > update. Thanks, I will do my best! :) Anton -- 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
2009/12/16 Anton Starikov : > > 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 ? > > Of course it is client error. But it is much easy to add "dirty hack" to > samba on server that fooling around bunch of clients. > Does Apple opensource their implementation of smbfs? http://www.opensource.apple.com/source/smb/smb-348.7/ -- James Peach | jor...@gmail.com -- 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
2009/12/16 Jeremy Allison : > 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 ? FileSync wants to create accurate copies of files, including all their metadata. We just pass the error up the stack. The current code does not look too closely at the unix capabilities, we should be looking at the flags mask in the UNIX_INFO2 response and handling the case where the server doesn't understand any flags. Please file a bug at http://bugreporter.apple.com and attach the packet trace. This will help us to make a case to fix this in an update. -- James Peach | jor...@gmail.com -- 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
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? 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
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 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 ? Of course it is client error. But it is much easy to add "dirty hack" to samba on server that fooling around bunch of clients. Does Apple opensource their implementation of smbfs? > > 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 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
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) On Dec 16, 2009, at 6:48 PM, 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
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 Wed, Dec 16, 2009 at 12:37:48PM -0500, 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... That was my initial reaction as well. This just can't be true, there must be something else. But it *is* a very weird phenomenon. Volker signature.asc Description: Digital signature -- 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
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
Re: [Samba] mac client: folder copy problem
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 ... :-) Volker signature.asc Description: Digital signature -- 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 Wed, Dec 16, 2009 at 06:19:05PM +0100, Volker Lendecke wrote: > On Wed, Dec 16, 2009 at 12:15:20PM -0500, Ryan Suarez wrote: > > Server is debian lenny w/ samba 3.3.9. > > Client is mac osx 10.5.x > > > > Client tries to copy a folder on share. Only the folder is copied, it's > > contents are not. An extra step is needed by the client to copy the > > contents into the new folder on the share. > > > > Anyone know of this problem? > > 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. 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 Wed, Dec 16, 2009 at 12:15:20PM -0500, Ryan Suarez wrote: > Server is debian lenny w/ samba 3.3.9. > Client is mac osx 10.5.x > > Client tries to copy a folder on share. Only the folder is copied, it's > contents are not. An extra step is needed by the client to copy the > contents into the new folder on the share. > > Anyone know of this problem? 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 :-) Volker pgpVFfbfAICXY.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] mac client: folder copy problem
Hi, Server is debian lenny w/ samba 3.3.9. Client is mac osx 10.5.x Client tries to copy a folder on share. Only the folder is copied, it's contents are not. An extra step is needed by the client to copy the contents into the new folder on the share. Anyone know of this problem? regards, Ryan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba