Uninstalling Smbup and Reinstall Samba/Reactivate Samba on Mountain Lion

There is an Uninstaller for it.

http://www.acryan.com/forums/viewtopic.php?f=91&t=19434

Try Google First.

Hello. Sorry for finding this thread so late. I do encourage people to ask me for support directly 🙂

When you install SMBUp it has to disable Apple's native SMB and netbios services. When you uninstall SMBUp (there's an option to do so in the menus) everything installed by it is removed but these services can't be re-enabled programmatically.

To re-enable windows file sharing you should do two things:

1.-Go to System Preferences -> Sharing -> Windows File Sharing . And re-enable the access (uncheck and check the checkbox twice, to make sure). This starts the SMB service.

2.-Go to Network -> Advanced -> WINS: Modify your machine name twice and apply. This "resets" Apple's native Netbios processes.

We keep trying to find a better way to do this but Apple hasn't provided ways to automate this easily.

I'm having trouble with this - I have followed your instructions for uninstall - I have reset the Netbios 4 times, file sharing, I have tried to uninstall SMBup and everytime I do, it says it did, but when I run it again, it's all setup the way it was before. Is there a way to do it all manally?

Please, keep in mind that SMBUp is only a front-end for Samba and two launch scripts. SMBUp itself has no "setup".

When you say "it's all setup the way it was" what do you mean? When you uninstall do you check all options in SMBUp? Does it say it's working?

The uninstall procedure only removes the installed packages (/opt/local, mainly) and the launch scripts:

/Library/LaunchDaemons/org.samba.smbd.plist

/Library/LaunchDaemons/org.samba.nmbd.plist

You can manually delete both and restart and it'll be as if you hadn't installed anything.

I personally would prefer to know what do you mean when you say you uninstalled and then everything is the same. You should be getting errors all over the place if the uninstall was failing.

I can't speak for the original poster but I can say that on my Mac Mini running 10.8.4 the uninstall does nothing. All the files you mention above are still there.

EDIT: and I'm uninstalling because SMBup doesn't work; mainly I cannot add users. I get the "15 groups" error message for one user and no message at all for another user.

EDIT2: never mind, it's a UI bug. When you open the uninstall dialog the "All installed" check box is checked but most of the items are NOT checked. I presumed, since it was checked, I didn't need to change anything. Toggling the "All installed" check box made it check *everything*.

EDIT3: after running the uninstall with "All installed" correctly checked, the entire /opt directory structure remains. It looks like most of the files are gone, but there are 200+ folders. Also the plist files you mentioned are NOT removed.

So, just to be clear, my Mini is now hosed, I cannot access and shares via Windows. I've deleted '/opt' as well as the plist files, toggled the WINS name over and over as well as starting and stopping file sharing numerous times and rebooting as well. I see a re-install in my future 😟

Hi.

Sadly, by now you've done all these actions I can't help much with. But I'll go through them anyway.

RE:EDIT1: This is a limitation from OS X that became obvious only after the current version came out. There's a simple one-line workaround to it but I didn't have time to tell you from the time you replied here to when you removed everything.

RE:EDIT2: From your first post I imagined there had been a confusion with the uninstall screen. I'll check the bug you mention, as it hasn't been reported before.

RE:EDIT3: The program only deletes its own files and won't touch anything else. If you had ever installed MacPorts, for example, the structure would remain (as it uses /opt) as well. If you had ever, even unknowingly, placed a file in that structure then it would also remain. Finally: If the program finds any problems removing (open files, permissions, etc.) the files will also remain.

To be clear: Nothing in /opt affects the machine's ability to use native services. It affects whether Samba can run or not, only.

If the plists where flagged for removal and weren't removed (they are NOT in /opt) either the folders have incorrect permissions or the files were in use. The program should make sure Samba isn't running but external factors may make it look as if it isn't already. The plist files, though, also don't make a difference to the local network services, they only start or stop the Samba services.

RE: Followup:

Continously restarting and reenabled/disabling services doesn't (and shouldn't) make a difference. From what I understand your mini is not hosed, but a single functionality for you is failing.

You say you "cannot access and shares via Windows". I imagine you mean you can't access any shared folders from Windows in the Finder. This has never happened before for any user, the common error is not seeing network shared in the Finder's sidebar but accessing the shares has always worked with or without SMBUp (Samba and SMBUP don't touch the Finder's ability to connect to network shares, but OS X loses the ability to automatically add servers to it sidebar if its netbios service is replaced).

Can you confirm whether you can connect directly to servers? "Finder -> Connect to Server" menu option should allow you to enter the server and connect to it.

If you can connnect to the server manually and what you're missing is seeing the shared servers in the sidebar, you can force the Apple netbios daemon to start:

Paste each of these lines separately in the terminal, since the first one will ask for your password and the rest won't. The first two lines make sure Samba is not running. The last two ensure Apple's netbios Daemon (the one that talks to the finder sidebar) is:

sudo launchctl unload -w /Library/LaunchDaemons/org.samba.smbd.plist

sudo launchctl unload -w /Library/LaunchDaemons/org.samba.nmbd.plist

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist

sudo launchctl start com.apple.netbiosd

First, thanks for the reply, really appreciate it.

When I say my Mini is "hosed" here is what I mean: I purchased this Mini to be a file server on my home network. I have at least 5 devices that need to access this server via SMB. So, without functional SMB sharing, the machine is useless.

RE:EDIT3:

I checked Time Machine for /opt. At 9:36 the folder did not exist. At 10:36 (after running SMBup) the folder existed. So, again, the uninstall failed to remove the folders.

If the plists where flagged for removal and weren't removed (they are NOT in /opt) either the folders have incorrect permissions or the files were in use.

I understand logically what you're saying, from a developer's perspective, but the fact remains your software created the files. The only reason they would be "in use" is because of changes your software made. These files did not exist prior to installing SMBup. I was able to delete them manually without issue and this is a brand new machine so I doubt this was a permissions issue though I am aware that permissions get screwed up in OS X all the time. Setting all of this aside, feedback from the uninstaller that it was unable to delete the files, and the reason for the failure would go a long way to making this clearer. Perhaps there's a log file I'm not aware of?

Continously restarting and reenabled/disabling services doesn't (and shouldn't) make a difference.

Then why did you suggest it?

You say you "cannot access and shares via Windows". I imagine you mean you can't access any shared folders from Windows in the Finder.

Negative. As I said before the Mini will act as a file server so I am trying to access shares on the Mini from a Windows machine. The mini is no longer visible on the network at all (e.g. from Windows Explorer) nor can I access it via the UNC path. Keep in mind you already suggested in this thread to reset the WINS name and I've already done that more than once.

I did not follow the rest of your suggestions in this most recent reply because that's not the problem I am having.

Thanks again.

jfletcher4d wrote:

First, thanks for the reply, really appreciate it.

When I say my Mini is "hosed" here is what I mean: I purchased this Mini to be a file server on my home network. I have at least 5 devices that need to access this server via SMB. So, without functional SMB sharing, the machine is useless.

Both Samba (of which SMBUp is just a front-end) and the native SMB installation work in countless installations. Samba and SMBUp should work in yours as well, as I mentioned, in the same way it works for everybody else. The issue you mentioned could be worked around but by the time I saw this post you'd already gone ahead and deleted the installation. Since it's a problem with OS X SMBUp can't fix it, but this is the closest I can do.

Still. If SMB1 access is too critical for you, enough to consider the purchase of a whole computer as waste, perhaps purchasing a proper SMB software, like Dave, would be worth it. They provide proper technical support so it may be better suited for your needs (although I tend to answer support questions via email and twitter, and both are linked in the application).

I checked Time Machine for /opt. At 9:36 the folder did not exist. At 10:36 (after running SMBup) the folder existed. So, again, the uninstall failed to remove the folders.

I'm not questioning the veracity of your statements. I'm just saying the only reasons I can think of for the folder not being deleted.

As stated, though, this is irrelevant to the issue of getting the native file sharing working again. As long as the service isn't running the files and folders are just bytes on the disk, not doing anything.

Continously restarting and reenabled/disabling services doesn't (and shouldn't) make a difference.

Then why did you suggest it?

I most definitively didn't suggest endlessly toggling the services, I can't imagine where you saw this. I suggested doing it twice in each of two places. The reason is that by experience people usually skip steps they consider unnecessary and since the toggle may seem to be enabled when in reality it isn't, asking users to flip it twice makes sure it's flipped at least once, always.

You have found a similar issue in SMBUp's uninstall window, which also was actually a bug and needed the check to be toggled again:

I presumed, since it was checked, I didn't need to change anything.

On the uninstaller:

Setting all of this aside, feedback from the uninstaller that it was unable to delete the files, and the reason for the failure would go a long way to making this clearer. Perhaps there's a log file I'm not aware of?

Point taken. If the new version is ever released I'll make sure to do something about unknown situations where folders or files are not removed.

I did not follow the rest of your suggestions in this most recent reply because that's not the problem I am having.

The suggestions you ignored reset the network services from OS X, so they might very well fix your problem, which is that your native network services are not working properly. This is what resetting the WINS name should do, but in your case it might not be doing it (plus, of course, making sure the native OS X file sharing has "SMB" enabled).

I'm not completely sure if you now want to share through the native OS X implementation, if you're looking for alternatives on how to share the files instead of SMB or if you're planning to try using Samba again (with or without SMBUp as intermediary). I might be able to help you, if you want to.

In the meantime, I have added a FAQ to the SMBUp page outlining some of these issues and workarounds.

http://eduo.info/2013/07/13/smbup-faq

I ended up restoring the Mini from a Time Machine backup prior to the SMBup installation. My Windows machines were imediately able to access the shares on the Mini again.

You wanted to know the context for why I tried SMBup: I was unable to complete a backup from a Windows install using Acronis True Image Home 2012 to a share on the Mini. After 5 minutes or so the backup would stall and behave like the share was no longer available. After some research I begain to find many messages about Apple's SMB failing with large file transfers and with some folks pointing to SMBup as a solution.

I ended up solving the problem in a different and probably better way: I'm backing up using FTP instead. It seems to be more reliable and perform better.

I haven't run into further SMB issues yet (for example I had no problem using rsync to synchronize my lossless music library on my PC with the Mini). I'd certainly prefer to stick with the "stock" experience if I can.

Thanks for your efforts.

This way worked for me:

0.) Only one user should be logged in.

1.) Uninstall the Daemons with the uninstall function of SMBup. You can find it in the menu bar. ATTENTION: deselect ALL and then select ALL. --> All Daemons will be selected in this way.

2.) Perform a restart of your computer.

3.) Go to Terminal:

sudo rm /Library/LaunchDaemons/org.samba.nmbd.plist

sudo rm /Library/LaunchDaemons/org.samba.smbd.plist

4.) Delete both files. (You can go to the Directory with: SHIFT+CMD+G).

5.) Delete:

/Applications/SMBup.app

~/Library/Preferences/info.eduo.smbup.plist

~/Library/Caches/info.eduo.smbup

~/Library/Application Support/SMBup

6.) Perform a restart of your computer.