I had set up a Samba server on SuSE linux a few years ago with a single shared directory. It has been running fine ever since, surviving various system upgrades and hardware migrations without ever needing to change the configuration (well, maybe once or twice).
However, since a few weeks ago, it refuses write access to the share.
It just returns NT_STATUS_ACCESS_DENIED when I try to create or write to a file. That’s also what /var/log/samba/log.smbd says (nothing more AFAICT).
It’s the same for all clients, i.e. remote Win XP PCs or local smbclient.
The funny thing is that it allows write access immediately after rebooting the server, but after a while (the next day or so) it refuses again.
Restarting smbd or nmbd doesn’t change anything here.
I suspect that this started after installing the latest security updates for OpenSuSE 11.2 on May 17th. The new packages were (according to /var/log/zypper.log):
Somehow I can’t see which of these might have an influence on samba.
But I am absolutely and positively sure that I didn’t change anything else. I logged into the server only once in months, and all I did was doing the updates using the updater applet.
Can anybody give me a hint where to look for a solution?
>
> I had set up a Samba server on SuSE linux a few years ago with a single
> shared directory. It has been running fine ever since, surviving various
> system upgrades and hardware migrations without ever needing to change
> the configuration (well, maybe once or twice).
>
> However, since a few weeks ago, it refuses write access to the share.
>
> It just returns NT_STATUS_ACCESS_DENIED when I try to create or write
> to a file. That’s also what /var/log/samba/log.smbd says (nothing more
> AFAICT).
>
> It’s the same for all clients, i.e. remote Win XP PCs or local
> smbclient.
>
> The funny thing is that it allows write access immediately after
> rebooting the server, but after a while (the next day or so) it refuses
> again.
>
> Restarting smbd or nmbd doesn’t change anything here.
>
> I suspect that this started after installing the latest security
> updates for OpenSuSE 11.2 on May 17th. The new packages were (according
> to /var/log/zypper.log):
>
> xorg-x11-libXext-2379.noarch
> libmysqlclient-devel-2315.noarch
> openSUSE-build-key-2398.noarch
> libpython2_6-1_0-2213.noarch
> libpng-devel-2159.noarch
>
> Somehow I can’t see which of these might have an influence on samba.
>
> But I am absolutely and positively sure that I didn’t change anything
> else. I logged into the server only once in months, and all I did was
> doing the updates using the updater applet.
>
> Can anybody give me a hint where to look for a solution?
>
>
drhok;
At best I can only suggest some hints/suggestions. I have no real explanation
for it suddenly failing and then working after a reboot.
First you might try adding this to the global section of /etc/samba/smb.conf:
log level = 3
This will give more complete Samba logs. You can raise the log level all the
way to 10 to get full debug logs. In my experience at log levels above 3
there is just too much chaff to find the wheat unless you really know what
you’re looking for. You need to restart Samba to make the new log levels
effective. Once you have this sorted out, remove this to keep your logs to a
reasonable level.
You might also want to check the reports from apparmor ( in /var/log/apparmor)
just in case it somehow starts blocking Samba. Be sure to
check /var/log/messages to see if something is logged there.
Since you said it works well after a reboot, at least for a while, I think the
answer may be failing hardware. Bad cable( network or hard disk)?; bad
memory (run a memory checker)?; bad switch; weak power supply, failing
network card. Make sure SMART is enabled for the disks (smartd). Maybe after
something heats up it fails.
Have you recently changed the permission setting to “secure” or “paranoid” ?
–
P. V.
“We’re all in this together, I’m pulling for you.” Red Green
>
> Thanks for your reply.
>
> I just found out it’s a hardware error. Apparently the disk is throwing
> spurious interrupts, so the kernel mounts it read-only as a precaution.
>
> Which is nice, but I didn’t notice it because ‘mount’ shows it as RW.
>
> So it’s not a Samba problem at all.
>
>
drhok;
Glad you got it sorted out. Software problems usually occur immediately and
under the same conditions. If something works for a period of time and then
fails, or fails intermittently then hardware problems are often to blame.
P. V.
“We’re all in this together, I’m pulling for you.” Red Green