SUSE 13.1, 3.11.6-4 x86_64, KDE 4.11
The latest thing I’ve discovered that has been broken by the latest series of updates is CIFS file sharing. I’m connected to a NAS device on the local network, and suddenly found myself unable to transfer files to and from the device. I can, however, view and browse the files over the network, just not open or transfer them.
Furthermore, I can not connect to localhost via the network: If I try to browse \127.0.0.1, I get a message stating “could not connect to host for smb://127.0.0.1/” That’s never happened before.
Here’s the output of " systemctl status smb.service "
systemctl status smb.service
smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled)
Active: failed (Result: resources) since Sat 2013-12-28 12:12:09 CST; 28s ago
Process: 7678 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited, status=0/SUCCESS)
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Starting Samba SMB Daemon...
Dec 28 12:12:09 openSUSE-laptop.site smbd[7678]: [2013/12/28 12:12:09.388210, 0] ../source3/param/loadparm.c:2376(s...e_ok)
Dec 28 12:12:09 openSUSE-laptop.site smbd[7678]: WARNING: No path in service netlogon - making it unavailable!
Dec 28 12:12:09 openSUSE-laptop.site smbd[7679]: [2013/12/28 12:12:09.389973, 0] ../lib/util/pidfile.c:117(pidfile_create)
Dec 28 12:12:09 openSUSE-laptop.site smbd[7679]: ERROR: can't open /var/run/samba/smbd.pid: Error was No such file o...ctory
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: PID file /run/samba/smbd.pid not readable (yet?) after start.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: smb.service never wrote its PID file. Failing.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Failed to start Samba SMB Daemon.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Unit smb.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
systemctl status smb.service -l
smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled)
Active: failed (Result: resources) since Sat 2013-12-28 12:12:09 CST; 2min 55s ago
Process: 7678 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited, status=0/SUCCESS)
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Starting Samba SMB Daemon...
Dec 28 12:12:09 openSUSE-laptop.site smbd[7678]: [2013/12/28 12:12:09.388210, 0] ../source3/param/loadparm.c:2376(service_ok)
Dec 28 12:12:09 openSUSE-laptop.site smbd[7678]: WARNING: No path in service netlogon - making it unavailable!
Dec 28 12:12:09 openSUSE-laptop.site smbd[7679]: [2013/12/28 12:12:09.389973, 0] ../lib/util/pidfile.c:117(pidfile_create)
Dec 28 12:12:09 openSUSE-laptop.site smbd[7679]: ERROR: can't open /var/run/samba/smbd.pid: Error was No such file or directory
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: PID file /run/samba/smbd.pid not readable (yet?) after start.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: smb.service never wrote its PID file. Failing.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Failed to start Samba SMB Daemon.
Dec 28 12:12:09 openSUSE-laptop.site systemd[1]: Unit smb.service entered failed state.
I just checked, there is no “/run/samba” or “/var/run/samba” on this machine.
How can I get my network file sharing services back online?
Furthermore, after stopping apparmor, I’m getting persistent tracker-miner processor spikes, and I still can transfer files to and from the NAS. My processor is currently at 90 degrees C, and shows no sign of slowing down.
Just run “sudo /usr/sbin/logprof” to update the Apparmor profile and allow smbd and nmbd to create that directory.
Then it should work fine with Apparmor again.
Furthermore, after stopping apparmor, I’m getting persistent tracker-miner processor spikes, and I still can transfer files to and from the NAS. My processor is currently at 90 degrees C, and shows no sign of slowing down.
You need Apparmor to prevent tracker from slowing down your system?
That’s an interesting approach… lol!
Just run “sudo /usr/sbin/logprof” to update the Apparmor profile and allow smbd and nmbd to create that directory.
Then it should work fine with Apparmor again.
I’ve had to do that twice; once, and then again after a reboot. The second time didn’t seem to change as many things, so we’ll have to wait and see if this is a fix, or a workaround I’ll have to invoke every time I reboot.
You need Apparmor to prevent tracker from slowing down your system?
That’s an interesting approach… lol!
Why don’t you just uninstall tracker then?
If I’m not mistaken, isn’t that what Apparmor is supposed to do?
whatis apparmor
apparmor (7) - kernel enhancement to confine programs to a limited set of resources.
Anyway, tracker-miner-fs has , in my experience, been known to go a little inexplicably nuts every now and then, but not often enough to warrant complete removal, seeing as how the indexing enhancement it provides probably outweighs the occasional trouble it provides.
You should have to do that only once!
But logprof will of course ask you about any other things that have been blocked as well. So of course there can be new things every time you run it.
But you should not just enable all of them, that would undermine Apparmor’s presence, you could just as well uninstall it then.
Only allow the stuff for smbd and nmbd (/var/run/samba and maybe /var/cache/samba should be enough, and of course the configured shares) and it should work without running logprof again.
If I’m not mistaken, isn’t that what Apparmor is supposed to do?
Well, actually its purpose is to increase security by not allowing selected applications to access all things they want.
But in tracker’s case it would be better to just configure it to not index the stuff you don’t want to index. I don’t know how this is done though, I guess with “tracker-preferences”. I never used tracker, this is one of the first things I uninstall, as I use KDE which has its own file indexer. No sense in running both…
But I wasn’t even aware that there was a profile for tracker included. Did you create one yourself?
And it sounded to me like you completely block tracker with Apparmor. In that case it really would have been better to just uninstall it…
Ah, if you’re referring to Nepomuk, I just assumed tracker-miner worked with it. If Nepomuk works completely independently of tracker-miner, then I suppose I could afford to get rid of it.
But in tracker’s case it would be better to just configure it to not index the stuff you don’t want to index. I don’t know how this is done though, I guess with “tracker-preferences”. I never used tracker, this is one of the first things I uninstall, as I use KDE which has its own file indexer. No sense in running both…
But I wasn’t even aware that there was a profile for tracker included. Did you create one yourself?
And it sounded to me like you completely block tracker with Apparmor. In that case it really would have been better to just uninstall it…
You probably know way more about it than I do. I have no idea how to configure tracker-miner, never tried, and probably never will, as I just uninstalled it.
That’s correct. Nepomuk and tracker (including tracker-miner) are separate things and work completely independent of each other.
If you want to search in an application that uses tracker (GNOME applications mainly, nautilus f.e.), you have to run tracker of course.
KDE applications like dolphin should use Nepomuk.
You probably know way more about it than I do. I have no idea how to configure tracker-miner, never tried, and probably never will, as I just uninstalled it.
Well, not really. The last time I searched for a way to turn off tracker I didn’t even find any, that’s why I always uninstall it…
Btw, you can configure Nepomuk (and its file indexer) in “Configure Desktop”->“Desktop Search”. But I guess you knew that already.
