[Samba] Writing operations to a Samba share fail

[elias at elekno.fi]

Walter Mautner kirjoitti:
> Am Tuesday 21 April 2009 13:30:28 schrieb Elias Knuutila:
>   
>>   Hi,
>>
>> I have a problem with Samba occasionally starting to fail with any write
>> operations to a public share. When Samba is started clean, everything
>> works OK. Then at some stage some users start to experience errors
>> trying to write into a share. At the same time other users may not
>> perceive any problems.
>>
>>     
> .....
>   
>> System is Suse Linux Enterprise Server 10 with Samba version
>> 3.0.22-13.23-SUSE-SLES10. Filesystem Reiserfs, with about plenty of free
>> space, RAID. Simultaneous connected clients up to ~15. Samba is also a
>> primary domain controller. Users log on it to authenticate into the
>> domain, with local (not roaming) profiles. No problems have appeared
>> with this.
>>
>> Samba log and strace shows errors that are not very helpful to me.
>> Following error messages are found in log.smbd:
>>
>> error packet at smbd/notify.c(55) cmd=160 (SMBnttrans) NT_STATUS_CANCELLED
>> error packet at smbd/trans2.c(2629) cmd=50 (SMBtrans2)
>> NT_STATUS_OBJECT_NAME_NOT_FOUND
>> error packet at smbd/nttrans.c(652) cmd=162 (SMBntcreateX)
>> NT_STATUS_OBJECT_PATH_NOT_FOUND
>> error packet at smbd/nttrans.c(95) cmd=160 (SMBnttrans)
>> NT_STATUS_NOT_A_REPARSE_POINT
>>     
>
> Looks like a forced reiserfschk is overdue.
>   

Have you experienced this personally? I didn't find any sign of 
scheduled file system checking in the system, that would conflict with 
samba. Hope that corrupt file system itself is not causing this. But 
this is output from debugreiserfs command:


Filesystem state: consistency is not checked after last mounting

Reiserfs super block in block 16 on 0x900 of format 3.6 with standard 
journal
Count of blocks on the device: 59737680
Number of bitmaps: 1824
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] 
blocks): 12814955
Root block: 6750614
Filesystem is NOT clean
Tree height: 5
Hash function used to sort names: "r5"
Objectid map size 18, max 972
Journal parameters:
       Device [0x0]
       Magic [0x31d77285]
       Size 8193 blocks (including 1 for journal header) (first block 18)
       Max transaction length 1024 blocks
       Max batch size 900 blocks
       Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 9429742
UUID: 7e39db7d-6705-486b-a3b6-173f51ec3c30
LABEL:
Set flags in SB:
       ATTRIBUTES CLEAN

Seems that something is wrong, but don't know how serious is it.