{12} All active tickets recently changed first (23 matches)

Upon a recent reboot, I saw this:

" Line 22 of _LoadOtherFuncs in evfsgui.VRM: +++ Call VRMessage 'Main', 'REXX function library 'strip(translate(word(sourceline(sigl -1),4),' ',",'))'.DLL is missing!','EVFSGUI fatal error','E'; "

Screenshot: ​http://asavage.dyndns.org/ftp/hosting/eCS/Samba/Samba_03b.png

It has not been seen since.

Steven Levine opines: "This looks like two problems. One is an intermittently unloadable DLL and another is a failure of the error reporting code.

sometimes SMBD crash with a SIGABRT

[2012/02/27 16:39:29,  1] smbd/service.c:make_connection_snum(1138)
  workstation (192.168.0.112) connect to service D initially as user root (uid=0, gid=513) (pid 735)
[2012/02/27 16:39:31,  1] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(C:\MPTN\ETC\samba\lock/locking.tdb): tdb_lock failed on list 6490 ltype=3 (Invalid argument)
[2012/02/27 16:39:31,  0] smbd/open.c:open_file_ntcreate_internal(1707)
  Could not get share mode lock
[2012/02/27 16:39:34,  1] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(C:\MPTN\ETC\samba\lock/locking.tdb): tdb_lock failed on list -1 ltype=3 (Invalid argument)
[2012/02/27 16:39:34,  0] locking/locking.c:share_mode_lock_destructor(747)
  store returned NT_STATUS_UNSUCCESSFUL
[2012/02/27 16:39:34,  0] lib/util.c:smb_panic(1686)
  PANIC (pid 735): could not store share mode entry
[2012/02/27 16:39:34,  0] lib/util.c:log_stack_trace(1840)
  unable to produce a stack trace on this platform
[2012/02/27 16:39:34,  0] lib/fault.c:dump_core(235)
  dumping core in C:\MPTN\ETC/samba/log/cores/smbd

Killed by SIGABRT
pid=0x02df ppid=0x003b tid=0x0001 slot=0x00b4 pri=0x0400 mc=0x0001
C:\PROGRAMS\SAMBA\SMBD.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

I have server and client installed on two (2) eCS machines, NETBios names HCM and HHCM. I have client access to both machines from Windows 7. I have client access to HHCM from HCM. I have no client access to HCM from HHCM.

The server installation on HHCM appears to be incomplete (no saving and updating of CONFIG.SYS and "homes" not created, even though it exists in the smb.conf file).

I executed the group of troubleshootinf tests on both HCM and HHCM (see the attached 2 files). On HHCM the domain is "BLACKBODY". It should be "HHCM. And there are other problems on HHCM, as indicated in these tests.

Symptoms: 3.5.19 nmbd stops working after some arbitrary time. For smbd no mor new connection is accepted, while older one still work.

Looking into log.nmbd I see plenty of these:

[2013/03/15 11:40:54.862000,  0] lib/util_tdb.c:385(tdb_log)
  tdb(D:\MPTN\ETC/samba/lock/wins.tdb): tdb_rec_read bad magic 0xd9fee666 at offset=6392
[2013/03/15 11:40:54.888000,  0] lib/util_tdb.c:385(tdb_log)
  tdb(D:\MPTN\ETC/samba/lock/wins.tdb): tdb_rec_read bad magic 0x42424242 at offset=5384
[2013/03/15 11:40:54.925000,  0] lib/util_tdb.c:385(tdb_log)
  tdb(D:\MPTN\ETC/samba/lock/wins.tdb): tdb_oob len 1113543791 beyond eof at 24576
[2013/03/15 11:40:54.925000,  0] lib/util_tdb.c:385(tdb_log)
  tdb(D:\MPTN\ETC/samba/lock/wins.tdb): tdb_rec_read bad magic 0x0 at offset=6704

for smbd.exe log entries look very similar.

Result is: nmbd.exe process is unkillable and smbd does not accept any new connection.

This problem also affects the client.

At the moment every GUI has to be built separately opening the VX-REXX IDE. The goal is to rebuild all GUI tools in one step.

Building an .exe from commandline works using the following switches (documented, but well hidden):

vrxedit /o smbusers.vrp /x smbusers.exe /q

A solution could be to create a wrapper net.exe that analyzes the parameters passed to it and select which net.exe was intended based on that. Hardly foolproof, this could be sort of a fix for many of the annoyances.

Another solution would be to simply rename the Samba version of net.exe (which would at least break the documentation)

One way or the other, this problem needs to be resolved.

While writing files from (L)unix client to OS/2 samba server, the client is unable to set file time/permissions.

Typical error code is 95.

Sample output from rsync: rsync: failed to set times on "/home/yuri/.gvfs/yuri su pippo/Dati/Yuri/grab": Operation not supported (95)

Same error using File Commander/Linux?.

Does not happen when files are copied using GUI (e.g. Nautilus).

Samba server 3.0.34, will test latest 3.3.x. Logs will be added.

add cups support to 3.5 line of servers

Basically this is a followup to Ticket #120. While the reason for Ticket #120 was the missing cache of our Samba Client, the reason for this ticket is, that the ammount of time OOo File Open Dialog needs to read a directory rises exponentially (for n directory entries it has to do n * n reads).

It appears that this is a problem of the OOo Filedialog and not of Samba as my tests on a directory with 4700 entries revealed:

• OOo 3.2.0 needs ages (never let the operation complete, killed it after 20 minutes), as it blocks the machine.
• OOo 1.1.5 which used the Odin-Filedialog does the same within 1-3 seconds.
• StarOffice 5.1a (which has a similar Filedialog as OOo 3.x) needs approximately 12 minutes (and does not block the machine).

Clients (WinXP and Netdrive) see files on the server, that have the hidden and/or system attribute set.

Clients (WinXP and Netdrive) seem to be able to change hidden, system, readonly attributes, but the attributes don't stick (it appears the server ignores these changes.

Clients (WinXP and Netdrive) can delete files on the server that have readonly attribute set.

It would be very nice to have a REXX DLL based upon rpcclient.exe which provides many RPC function to obtain an set various informations on a (remote) Samba Server.