[Samba] Re: files being blanked by writing

[Jason Joines]

Jason Joines wrote:
> Jason Joines wrote:
> 
>>     I'm running Samba 2.2.8a on SuSE Linux 8.1 with kernel 2.4.19.  I 
>> have a share defined by this on a web server to allow members of the 
>> jamigos group to edit web pages.
>>
>> [users]
>>         comment = User Web Pages
>>         path = /home
>>         valid users = @jamigos
>>         read only = No
>>         create mask = 0664
>>         force create mode = 0664
>>         directory mask = 0775
>>         force directory mode = 0775
>>         browseable = No
>>
>>     I received a few complaints of save errors followed by missing web 
>> pages so I decided to check it out.  Via this share, I opened the file 
>> /home/wasdnord/public_html/4133/1RIGHT.HTM with Mozilla.  Here were 
>> the permissions at the filesystem level ahead of time.  The group 
>> jamigos is one of my supplementary groups.
>>
>> drwxrwsr-x+   2 wasdnord    jamigos       104 Sep 21 11:38 ../4133 and 
>> stat shows permissions of 2775.
>> -rw-rw-r--+   1 wasdnord    jamigos      2334 Oct 16  2003 1RIGHT.HTM
>> and stat shows 0664.
>>
>>     I made a small change, added a word to the bottom of the file, and 
>> tried to save it.  This gave me the rather generic error of "Saving 
>> File failed!" via Mozilla Composer.  I looked at the file on the 
>> server to see this:
>> -rw-rw-r--+   1 wasdnord    jamigos         0 Sep 21 12:00 1RIGHT.HTM
>>     What was being reported to me as missing pages was actually files 
>> having their contents erased.
>>
>>     I deleted the file and saved again, this time with no problems 
>> yielding:
>> -rw-rw-r--+   1 joines   jamigos      2626 Sep 21 12:19 1RIGHT.HTM.
>>
>>     It's not an issue of file permissions as I can make the changes 
>> with vi directly on the filesystme with no problem.  It's not an 
>> editor issue as I tried both Mozilla and Kate on Linux whereas the 
>> problems reported to me were with a wide variety of editors including 
>> frontpage on windows. Once I own the file, it all works as expected.
>>
>>     Just before trying this I turned the log level up to 3 and here's 
>> what I got:
>>
>> [2004/09/21 11:59:43, 3] smbd/dosmode.c:unix_mode(111) 
>> unix_mode(wasdnord/public_html/4133/1RIGHT.HTM) returning 0664
>> [2004/09/21 11:59:43, 3] 
>> smbd/oplock_linux.c:linux_set_kernel_oplock(186) 
>> linux_set_kernel_oplock: got kernel oplock on file 
>> wasdnord/public_html/4133/1RIGHT.HTM, dev = 805, inode = 8439294, 
>> file_id = 435
>> [2004/09/21 11:59:43, 2] smbd/open.c:open_file(247) joines opened file 
>> wasdnord/public_html/dnor.jpg read=Yes write=No (numopen=1)
>> [2004/09/21 12:00:02, 2] smbd/open.c:open_file(247) joines opened file 
>> wasdnord/public_html/4133/1RIGHT.HTM read=Yes write=Yes (numopen=1)
>> [2004/09/21 12:00:02, 3] 
>> smbd/trans2.c:call_trans2setfilepathinfo(2394) 
>> call_trans2setfilepathinfo(6) wasdnord/public_html/4133/1RIGHT.HTM 
>> info_level=1004 totdata=40
>> [2004/09/21 12:00:02, 3] smbd/error.c:error_packet(94) error string = 
>> Operation not permitted
>> [2004/09/21 12:00:02, 3] smbd/error.c:error_packet(113) error packet 
>> at smbd/trans2.c(2859) cmd=50 (SMBtrans2) NT_STATUS_ACCESS_DENIED
>>
>>     Naturally, there was tons of other stuff in the log at this level 
>> so I'm not even sure if these errors in the log are related to this 
>> particular problem.
>>
>>     Any ideas?
>>
>> Thanks,
>>
>> Jason Joines
>> =================================
>>
> 
>     It gets even more bizarre.  I have another share for access to 
> non-user web sites by a variety of editors.  It is set up like this:
> [web]
>   comment = Web Server
>   path = /local/htdocs
>   browseable = No
>   read only = No
>   create mask = 0664
>   directory mask = 0775
> 
> 
>     A directory and file I need to edit looks like this:
> drwxrws--x+  14 joeblow  cbaweb      20480 Sep 24 16:47 undergraduate/
> -rw-rw-r--+   1 joeblow  cbaweb       2434 Sep 24 16:47 
> undergraduate/studentorganizations.php
> 
>     I have access to this directory and files via the admin group and ACLs.
> 
> getfacl undergraduate/
> # file: undergraduate
> # owner: joeblow
> # group: cbaweb
> user::rwx
> group::rwx
> group:admin:rwx
> mask::rwx
> other::--x
> default:user::rwx
> default:group::rwx
> default:group:admin:rwx
> default:mask::rwx
> default:other::--x
> 
> getfacl undergraduate/studentorganizations.php
> # file: undergraduate/studentorganizations.php
> # owner: joeblow
> # group: cbaweb
> user::rw-
> group::r--
> group:admin:rwx                 #effective:rw-
> mask::rw-
> other::r--
> 
>     Now, using VI on the actual filesystem I can edit this file all I 
> want to and everything behaves as expected.  However, using any editor 
> via Samba I can only edit the file once, the second time it blanks it 
> and sets it to zero bites.
>     This is a repeatable situtaion:
> Open the file, add a character, save, all is well.
> Add another character, save, get editor specific errors and a zero byte 
> file.
> 
>     I removed the ACLs and added myself to the owning group, cbaweb.  I 
> can still edit just fine locally.  However via SMB I now get the same 
> editor specific error but the file is not zeroed.  I just can't change it.
>     Don't know if it's relevant or not but I'm using posixgroups stored 
> in OpenLDAP.
> 
>     Any ideas anyone?
> 
> Thanks,
> 
> Jason Joines
> ================================
> 

	Seems there is a bug in mount.cifs at least and maybe elsewhere related 
to supplementary groups, perhaps only when stored in ldap.  The reports 
form users of application on non-Linux platforms were erroneous.  The 
problems they encountered were related to them have exceeded filesystem 
quotas.  Everything seems to work fine from windows clients.

	I had recently started using mount.cifs instead of mount.smbfs because 
of a case-sensitvity issue in mount.smbfs.

	This seems to be buggy and is repeatable:

(1) Create a directory and file on a samba shared filesystem.
Add a user to the owning group of the directory and file so that the 
owning group is now one of that user's supplementary groups.
The user has no access to files beyond what "other" has.

(2) Create a filesytem ACL on the directory and file to allow the 
primary group of the user read/write access to the directory and file.
Now user can open file, edit, and save twice with no problem.
On third save, error occurs and file is set to zero bytes.

Jason Joines
=================================