PDA

View Full Version : Windows 7 RC and/or Samba problem



somebody
18-09-2009, 11:44 AM
I have a bizarre problem when trying to stream large files across the network from my linux-based fileserver to my netbook running Windows 7 (RC). After a period of time (I think it's after a couple of GB has been sent across the network), it appears the samba session locks up and stops transferring data. When this happens, I can no longer access any network shares on the file server.

I tried a number of things:
- Bouncing samba - didn't work
- Restarting my netbook - didn't work
- Trying to re-map the network drive - didn't work

The smbstatus command told me that there were read-only locks on several of the files I was interested in, although I don't understand why this would stop me accessing any network share on that fileserver.

In the end, the way I solved it was by forcibly terminating the samba sessions (I first had to change my smb.conf file as there was a deprecated option I had set which smbcontrol didn't like), then bouncing samba, changing smb.conf back to what I originally had, and bouncing samba again.

This problem has occurred several times in the last week or so, and seems to happen after a few GB has been transferred. Previously the way I "fixed" the problem was by rebooting both the server and my netbook.

Does anyone know what might be causing this problem, and what I can do to stop it happening again?

Erayd
18-09-2009, 12:06 PM
Does anyone know what might be causing this problem, and what I can do to stop it happening again?
Does samba access the shared filesystem via nfs by any chance?

You should be able to stop this happening by messing with the samba locking restrictions - there are several options which you'll probably find useful, although I can't remember them off the top of my head.

somebody
18-09-2009, 12:09 PM
Does samba access the shared filesystem via nfs by any chance?

You should be able to stop this happening by messing with the samba locking restrictions - there are several options which you'll probably find useful, although I can't remember them off the top of my head.

Samba is accessing /dev/sdb1 formatted in reiserfs.

Erayd
18-09-2009, 12:19 PM
Hmmm, that should be fine. Have a play with the locking / sync options and see what you can find - if that doesn't work, paste your config file here and I'll take a look.

Chilling_Silence
18-09-2009, 04:18 PM
Lets take a nosey at that smb.conf file :D

somebody
18-09-2009, 04:23 PM
Relevant parts below.


[global]
log file = /var/log/samba/log.%m
load printers = no
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .
obey pam restrictions = yes
socket options = TCP_NODELAY
null passwords = yes
encrypt passwords = yes
passdb backend = tdbsam
passwd program = /usr/bin/passwd %u
dns proxy = no
netbios name = fileservername
printing = cups
server string = fileservername
invalid users = root
workgroup = workgroup
os level = 20
syslog = 0
security = user
panic action = /usr/share/samba/panic-action %d
max log size = 1000
map to guest = Bad User
strict locking = no


[MyShare]
writeable = yes
valid users = MyUser
user = MyUser
only user = yes
path = /mnt/shared

Erayd
18-09-2009, 05:35 PM
Try setting 'locking = no' (either globally or on problem shares) - does this fix the problem?

If not, try setting the following on the problem shares:

oplocks = false
level2 oplocks = false
Any joy?

somebody
18-09-2009, 05:41 PM
Try setting 'locking = no' (either globally or on problem shares) - does this fix the problem?

If not, try setting the following on the problem shares:

oplocks = false
level2 oplocks = false
Any joy?

Thanks Erayd. I'll give it a go and see what happens.

somebody
21-09-2009, 11:34 AM
After a few days of testing, the problem has not gone away.

Erayd
21-09-2009, 02:44 PM
Can you run samba in debug mode and post the relevant bits of the log please?

somebody
21-09-2009, 02:48 PM
Can you run samba in debug mode and post the relevant bits of the log please?

Ok - it'll take a while for me to do this, as replicating the problem is time consuming (takes around 50 minutes of continuous file transfer before it crashes).