This is partially a tutorial and partially simply a record of how I have dealt with current problems systemic across all linux distributions with Samba networking and the gvfsd-smb-browse bug. The gvfsd-smb-browse bug, if you are not already aware, is a bug where, if you try and access any samba share, gets turned on and causes your CPU to run very hot and at 100%. Consequently, your Samba share will probably time out before it opens and you system will run very sluggishly.
The solutions I am about to outline are based partially on what other users have told me about on here and partially are my own.
To firstly deal with this bug we need to stop gvfsd-smb-browse from loading at login. An obvious solution might be to simply uninstall it. However, it is part of the gvfs package and, if it is uninstalled, it is going to take that whole package down with it. Gvfs does lots of other jobs and so if it is removed, your system may break in other ways. So, this simple solution is not available. Instead, it needs to be selectively disabled. There are two methods for doing this. One which I have read about and will repeat here and another one, of my own invention, that I use because the first one raises other problems for me. I will describe them both here and explain why I have chosen to implement the second one:
The first solution revokes permission on the gvfsd-smb-browse process. With that, the process won’t run on its own as it would require sudo access.
Open a terminal and use the following command:
sudo chmod 744 /usr/lib/gvfs/gvfsd-smb-browse
Now when you start your system or do anything on your system that might invoke gvfs-smb-browse, it cannot load because it can not gain root permission to do so.
However, I have a secondary problem in that I always disable sudo on my system, for other reasons I am not going to go into here. This means that any sudo based command can be invoked without the need of a password. This is a problem vis a vis the above solution because it means that applying the sudo command to gvfs-smb-browse would not now stop it from loading. My own personal solution to that is the following:
This solution sends a continuous kill command to gvfs-smb-browse during any given session.
open Pluma text editor
Paste the following into it:
sleep 10
while true; do killall gvfsd-smb-browse; sleep 30; done
Save the file as "kill-gvfsd-smb-browse.sh" and then close it.
Open caja and navigate to where you have saved your file. right click it and choose "properties". then go to the "permissions" tab and check the "allow executing file as program" checkbox. Then close the "properties" dialog box.
In the main menu, go to "system/preferences/personal/startup applications
Click the "add button to add an entry into the startup list
Type what you want in the "name" field". For the command field, navigate to your "kill-gvfsd-smb-browse.sh" file and select it. Then click the "save" button and exit the "startup applications" dialog box.
From now on, whenever you boot up/log in, gvfsd-smb-browse will be killed and then will be checked to see it is running every 30 seconds and, if it is running, will be killed again. I have this bash script running in the background on my own machine and can confirm it does not take up any measurable cpu resources itself. So, it is perfectly fine to run for an entire session with no ill effects.
Okay, so, with the gvfsd-smb-bug disabled, no more overheating CPU problems. But, no more Samba either (not that it was running properly anyway). So, our next problem is, firstly, how to get network sharing back up and running between my Linux machines and, secondly, how to get network sharing between Linux and MS Windows back up and running (which is one of the things Samba is built to do). Consequently, I will split the solutions to these two related problems into two parts:
- How to get network sharing between Linux machines working again
This solution involves the use of something called "SSH". which is a networking solution for Linux machines. I am led to understand Windows also uses some form of SSH, but that Windows and Linux machines cannot communicate with each other with it. Though, I am happy to stand corrected on that. One of our regular posters, Ouroumov, explained it to me the other day. It works really well and so I will repeat it here:
Machine A:
sudo apt-get install ssh
Machine B:
sudo apt-get install install ssh
cd ~/.ssh
ssh-keygen -t rsa -b 4096
ssh-copy-id you@MachineA_IP
To get the ip address for any eth or wifi card on a machine, open a terminal and type ifconfig
Once you have implemented the above, you should be able to connect to Machine A from Machine B using Caja.
Go to Caja, Hit CTRL L to reveal the address bar and enter the following into it:
ssh://you@MachineA_IP/path to shared folder/
Then you should see your machine A shared folder inside Caja on machine B
Bookmark it to complete the procedure. Then, the next time you fire up machine B, you should just select the bookmark in Caja and it will directly open up the network location.
The above procedure can be implemented in reverse as well so that machine A can access machine B's files.
- How to get networking between Linux machines and MS Windows machine working again
These solutions were given to me by @lah7 the other day. I haven't tried these out but will simply repeat them here:
If the Windows machines are just downloading/uploading files from Linux via SSH/SFTP (but not streaming), they could install FileZilla or run FileZilla Portable.
Or if there's a folder you'd like to temporarily serve, Python can host a basic HTTP server on the spot:
cd /path/to/my/files python -m SimpleHTTPServer 8080
I can't confirm how well the above solutions to sharing with MS Windows machines are since I have not implemented them. Instead, I have done something a bit different involving a program called btsync. You can get this in the software boutique. It is an alternative to cloud storage that allows two or more machines to sync a folder up so that they all share a continuously synced copy of it. In that sense, it is a kind of fake network sharing. However, for my limited needs vis a vis occasional MS Windows users on my network, it suffices. Furthermore, there is no limit to the size of the folder to be shared and no issues with cloud storage security since it is direct peer to peer. Nevertheless, I would not share highly personal files using btsync just to be on the safe side since it is being synced over the internet.
I have just installed btsync so that all members of my immediate family can sync our electronic photo albums together. Some of us use Linux and others use MS Windows, It's working outstandingly and is remarkably fast to sync. The album is over a gig and only took about 1/2 an hour to transfer the full album over the internet between me and my son's MS Windows machine. This is more than sufficient for file transfer needs when my sons and other extended family members come visiting with their various windows devices. No good for streaming of vids from my server to their machines of course. But, the sync time is sufficiently fast that with a slight amount of notice and delay I can simply transfer a vid over via btsync on request. So good enough for the relatively rare occasion when that is wanted.
Hope all of the above is useful.
. I personally don’t use Samba but I know a lot of people do!. 