I upgraded all my servers from 3.0.24 to 3.0.25 a couple weeks ago. My users have discovered and I can reproduce a problem with Windows XP offline files feature. I compiled and tested 3.0.25a today, the issue still exists. I can run 3.0.24 with the exact same smb.conf as 3.0.25a and it works perfectly. Specifically a folder on a share or even an entire share can be configured as "make available offline". Tell it to synchronize, synchronization appears to go fine. Unplug the PC's network cable forcing it go offline. XP tells you you're working offline. All the files are still listed in the folder as they should be. The problem comes when trying to open any of the files while offline, Windows just pops up an error saying "This file could not be found". Something I've noticed is that if I go into My Computer --> Tools --> Folder Options.. --> Offline Files tab --> View Files It shows all the file names as it should, in the "Synchronization" column most of the files will show "File is Synchronized" but many will display "Local copy is incomplete" even immediately after doing a synchronization. Even more significantly (I guess), in the Access column every file is listed as "User W" whereas if I sync to Samba 3.0.24 the Access column lists "User R/W" for each file. Also under 3.0.24 every file is listed as synchronized there are no Local copy is incomplete entries.
Can you try setting the option : map acl inherit = yes (with EA support on the filesystem) and see if this fixes it please ? Thanks, Jeremy.
Jeremy, Sorry meant to mention, before I entered this bug report I searched and found where you suggested that setting for someone else who is having s smiliar issue with Vista I had already tried map acl inherit = yes before entering this bug report. It made no difference. This is Solaris with UFS filesystem. For the record, I do specify --with-acl-support when I configure. Tom Schaefer
Does ufs support EA's ? I'm not sure it does.... It's definately an issue with the ACL's being returned on these files. I'd be interested in a debug level 10 between 3.0.24 (where it works) and 3.0.25 where it doesn't for the same file so I can see what the difference in the ACL mapping from POSIX to Windows is. I didn't think anything had changed in this code (although there was one bugfix but that shouldn't have caused this problem). Jeremy.
Can you tell me what the POSIX permissions are on the files causing a problem. I'm travelling tomorrow, but might get some time to try to reproduce and fix this over the weekend. Thanks, Jeremy.
Does UFS support EAs? No, at least not Solaris 8 which is what my main Samba server is running on. Apparently Solaris 9 does have some sort of EA functionality, I've never used it though. What are the Posix permissions of the files giving me trouble? Directories 755, files 644, I guess thats what you're wanting to know. Ok, I've made 2 level 10 logs. http://www.umsl.edu/~schaefer/3.0.24.log.smbd http://www.umsl.edu/~schaefer/3.0.25a.log.smbd Both logs where created identically, same server same files, same smb.conf same everything except for the version of Samba. smb.conf was this.. # Global parameters [global] workgroup = umsl-users netbios name = stercus interfaces = 134.124.15.43/24 127.0.0.1 bind interfaces only = Yes encrypt passwords = Yes debug level = 10 max log size = 75000 name resolve order = lmhosts wins bcast host host msdfs = no msdfs root = no preferred master = False wins server = 134.124.45.45 map archive = No security = user map acl inherit = Yes [Homes] comment = Home Directories writeable = Yes browseable = No valid users = %S Normally I use security = domain but I figured for the purpose of these logs I'd try and keep things simple and so security = user. (More on that in a moment, please continue reading to the end Jeremy) To make the logs I connected to a home share, schaefert, that was completely empty except for one single folder named "available_offline_folder" which contained one single file named "samba aka dirty dancing.doc". I right clicked on the folder, hovered my mouse pointer over "make available offline", issued cat /dev/null > log.smbd on the samba server and then immediately clicked on "make available offline" which immediately performs a synchronization, then immediately stopped samba. I used that exact procedure for both logs. All righty, back to the security = user bit, yesterday I filed another bug report 4674 https://bugzilla.samba.org/show_bug.cgi?id=4674 which pertains to me having problems with 3.0.25 smbclient. I brought it up in on the Samba mailing list a couple weeks ago and you even sent me a big patch to try at one point which did not resolve the problem. Funny how this all comes around full circle, today when I made the nice and simple security = user, smb.conf file above at first I couldn't get connected. I was like what the heck. Anyway, getting to the point.. I discovered that when I'm running 3.0.25a security = user it fails if the user's password is over 8 characters in length, 3.0.24 didn't matter. As far, as bug 4674 goes, that led me to determining today that the difference between successfully connecting with 3.0.25 or above's smbclient to my security = domain servers is whether or not the user's password is greater than 8 characters or not. I probably ough to put this info into that bug report. Maybe I should even open an additional bug report for security = user, password can't be greater than 8 characters.
I went ahead and opened a new bug, bug 4677, for the problem described above.
Created attachment 2733 [details] Patch Words fail in describing how much I suck. I shouldn't have made this mistake. This was an off-by-one in writing the access mask. This will be fixed for 3.0.25b (or above). Jeremy.
Fix committed to SAMBA_3_0, SAMBA_3_0_26, SAMBA_3_0_25. Jeremy.