Windows 98/ME Clients Hanging when viewing Samba 4 share in Windows Explorer \ VOGONS

Windows 98/ME Clients Hanging when viewing Samba 4 share in Windows Explorer

Topic actions

First post, by maxtherabbit

Posted on 2025-08-31, 12:50

maxtherabbit Offline

Rank l33t

Rank: l33t
Posts: 3729
Joined: 2018-10-30, 16:36
Location: Richmond, VA

I have a samba 4 NAS setup wide open - everyone maps to guest, no passwords. Please keep your comments about the "security" of this setup to yourself - I literally do not care.

Now that's out of the way, the issue is this: Windows 98 and ME clients can map the shared drive without issue; but when you try to view the contents, explorer will hang up for a very long time. The duration of the hangup appears to be directly proportional to the number of files that windows explorer tries to "preview" and in fact if you run smbstatus on the linux box during the client's hang time you can see that the client is requesting locks on every EXE, DOC, SCR, etc. file in the directory. Essentially any file that explorer would read a resource (icon, explorer bar preview) from when listing a directory.

Eventually the client will un-freeze and you can go about your business, but trying to do any meaningful file management in this condition is not practical, and further the client never releases the majority of its locks. This requires using smbstatus to list the worker PIDs for each process responsible for locking the client's files and kill -9ing them.

WfW 3.11, MS Net Client for DOS 3.0, Windows NT 3.51/4/2k/XP clients all access the same share without issue.

SMB conf file included below

1[global]
2	netbios name = OpenWrt 
3	interfaces = br-lan 
4	server string = Samba on OpenWRT
5	unix charset = UTF-8
6	workgroup = WORKGROUP
7	wins support = yes
8	bind interfaces only = yes
9	deadtime = 15
10	enable core files = no
11	security = user
12	invalid users = root
13	map to guest = Bad User
14	null passwords = yes
15	passdb backend = smbpasswd
16	socket options = IPTOS_LOWDELAY TCP_NODELAY
17	load printers = No
18	printcap name = /dev/null
19	disable spoolss = yes
20	printing = bsd
21	mdns name = mdns
22	preferred master = yes
23	veto files = /Thumbs.db/.DS_Store/._.DS_Store/.apdisk/
24	delete veto files = yes
25	server min protocol = LANMAN1
26	lanman auth = yes
27	ntlm auth = ntlmv1-permitted
28
29[media]
30	path = /mnt/sda1/media
31	create mask = 0666
32	directory mask = 0777
33	read only = no
34	guest ok = yes
35	vfs objects = io_uring
36
37[retro]
38	path = /mnt/sda1/retro
39	create mask = 0666
40	directory mask = 0777
41	read only = no
42	guest ok = yes
43	vfs objects = io_uring

Reply 1 of 2, by maxtherabbit

Posted on 2025-09-01, 01:11

maxtherabbit Offline

Rank l33t

Rank: l33t
Posts: 3729
Joined: 2018-10-30, 16:36
Location: Richmond, VA

I got quite excited this even when I found the parameter "reset on zero vc = yes" as this seems to be the exact cure for my problem, but adding it to my conf did absolutely nothing. I'm still getting 4-5 multiple connections from the same win9x client on the same IP, each one persisting indefinitely and leaving unreleased locks. There is some talk the parameter was removed from samba 4, but testparam shows it sure enough.

Other things I've tried to no avail:
using actual user based authentication
disabling oplocks
disabling all file locking
using different windows 98 PC client (they all behave the same)
changing server min version from LANMAN1 to NT1

samba version is 4.18.8 btw

Reply 2 of 2, by maxtherabbit

Posted on 2025-09-01, 13:33

maxtherabbit Offline

Rank l33t

Rank: l33t
Posts: 3729
Joined: 2018-10-30, 16:36
Location: Richmond, VA

FIXED!
The solution was to add "strict sync = no" to the global config.

From the man page:

This parameter controls whether Samba honors a request from an SMB client to ensure any outstanding operating system buffer contents held in memory are safely written onto stable storage on disk. If set to yes, which is the default, then Windows applications can force the smbd server to synchronize unwritten data onto the disk. If set to no then smbd will ignore client requests to synchronize unwritten data onto stable storage on disk.

In Samba 4.7.0, the default for this parameter changed from no to yes to better match the expectations of SMB2/3 clients and improve application safety when running against smbd.

The flush request from SMB2/3 clients is handled asynchronously inside smbd, so leaving the parameter as the default value of yes does not block the processing of other requests to the smbd process.

Legacy Windows applications (such as the Windows 98 explorer shell) seemed to confuse writing buffer contents to the operating system with synchronously writing outstanding data onto stable storage on disk. Changing this parameter to no means that smbd(8) will ignore the Windows applications request to synchronize unwritten data onto disk. Only consider changing this if smbd is serving obsolete SMB1 Windows clients prior to Windows XP (Windows 98 and below). There should be no need to change this setting for normal operations.

Default: strict sync = yes

Wish I had thought to search the man page for "windows 98" earlier, since this was only 1 of 2 places which mention it.

Go to top of page Go to top of page

Back to Software