Can't use mount_smbfs as root?

Could you go the other way and have the PC mount a volume on the Mac and copy its backup files when they change?

If that's to be automated in anyway, that sounds like "modifying the PC" to me, which as I said, "isn't an option".

I'm not familiar with Open Directory

This helps clarify quite a lot. I would suspect that you would therefore not be familiar with OS X Server either, which IMO, reveals a lot about what Apple considers to be the OS X way.

Why is that? Could it be that /Volumes is a special place perhaps?

Uh, yes. Exactly! It's a special place for, hmmm, maybe putting VOLUMES?!?

The longer I think about your assertion that /Volumes is reserved for the Finder, the more ridiculous I think it is. When Time Machine is backing up to a Time Capsule when no user is logged in, guess where it puts that mount point? With no user logged in, the use of the hdiutil command puts mounted disk image volumes, in... wait for it.... /VOLUMES!

/Volumes is the de facto standard OS X destination for the mounting of volumes, virtual, physical or network, for ANY application, and until you can present some documentation or evidence to the contrary, I feel your continuous assertion otherwise discredits any advice you're giving.

You can always do "rmdir" without a "-r" option.

Or maybe I could use the command made for unmounting volumes to unmount my volume?!?!

An even wiser choice is checking result codes and stopping your script on failure.

Don't worry, I'll do that too.

jaydisc wrote:

This helps clarify quite a lot. I would suspect that you would therefore not be familiar with OS X Server either,

That is correct. I don't need all the services that Lion Server provides. My use of MacOS X is as a client. Of course, that seems to be what you are doing as well, so I don't see how that matters. If you feel you need more specific information about Lion Server, I suggest you ask a question in the Server forum. Don't hijack someone else's question like you did here.

which IMO, reveals a lot about what Apple considers to be the OS X way.

I don't get that at all.

The longer I think about your assertion that /Volumes is reserved for the Finder, the more ridiculous I think it is.

You are the one having trouble with it, not me.

/Volumes is the de facto standard OS X destination for the mounting of volumes, virtual, physical or network, for ANY application, and until you can present some documentation or evidence to the contrary, I feel your continuous assertion otherwise discredits any advice you're giving.

cat /etc/auto_master ? Those are the standard destinations for network volumes. A system administrator can also configure any physical volume to be mounted outside of /Volumes. I don't see why you persist in arguing instead of just trying it. There is no reason to use root or /Volumes. It sounds like you are just used to Linux where everything is donen with root. That isn't the case on MacOS X.

Holy cow. This will be my last attempt/reply.

1. I showed you the tests with different users. The mount command only worked in an unattended manner when invoked as root using launchd.

2. I showed you tests with different mount points. Mounting in the /Volumes directory (unlike mounting elsewhere) ensured proper cleanup occured when unmounting. When observing the behavior of countless other Apple-bundled binaries, this is obviously the recommended location.

This works.

This is not a hack.

This is in line with the documentation.

This will not be overwritten by an OS update.

This answers the original posters question.

If you think you have a better solution, test it yourself, and by all means, reveal it. Otherwise you're just full of hot air and misnomers.

If anyone else, like myself or the original poster, is curious about how to get mount_smbfs or mount -t smbfs to run in an automated fashion, run it as root using launchd.

jaydisc wrote:

If you think you have a better solution, test it yourself, and by all means, reveal it. Otherwise you're just full of hot air and misnomers.

OK. I did. It works fine when I mount it as a user, either from the command line, from a launchd script, or from autofs. I tried it as root too and, strangely enough, it doesn't work. Maybe I should spend 3 or 4 days fighting with it. Nah! After all, what do I need root for?

Although I was able to mount in any directory, including /Volumes, I still wouldn't recommend using that directory. Just because it works for me does not mean it would necessarily work for anyone else. Who knows what strange things might happen?

If anyone else, like myself or the original poster, is curious about how to get mount_smbfs or mount -t smbfs to run in an automated fashion, run it as root using launchd.

There are quite a few nice ways to mount an smb share, and that is not one of them. Some suggestions are:

autofs

Finder > Go. The Finder can use your credentials in the keychain.

Creating an alias (via option + command drag) and then open that alias. It will automatically mount the server using your credentials in the keychain.

Scripting the above Finder operations

You can also use the command-line and lauchd script, but that would only be for advanced users.

Normally I use sshfs because the smb servers I have access to really don't have any data that I need on a regular basis. Normally I just use the Finder for those. Still, it was nice to play around with smbfs for a change. Apple's re-written SMB implementation is so much nicer than that open source sshfs junk.

There. is. no. logged-in. user.

There. is. no. instance. of. Finder.

This. is. a. server.

This thread is already for the people in this group:

You can also use the command-line and lauchd script, but that would only be for advanced users.

That's what we're troubleshooting here. The examples given are run in the command line. In my case, I've written my own shell script, I've written my own launchd.plist, and you're telling me to use the Finder. I'm now convinced. You. simply. don't. read. Good day.

I am just trying to suggest ways that you might be able to get it running. There is no requirement to use root on a server. Furthermore, you are not exercising any of Lion Server's capabilities. In your example, the PC is the server.

I was able to use smbfs from both the command line and launchd with no problem. Obviously something is misconfigured on your machine. Considering your recalcitrance, trying to identify and fix the problem would be just too painful. I suggest erasing your hard drive and reinstalling Lion. That would be the fastest way to return to a known, good state where smbfs will function normally.

If you sincerely believe the problem is due to your Server version if Lion, you should follow my advice above and look in the server forum. I'm sure there is a thread you can hijack over there.

I'm seeing this poblem as well. The problem so far seems to be when uid!=euid, particularly when running under sudo. For example:

As a regular user:

rnapier$ mount -t smbfs smb://admin:admin@rat-win7/kace /tmp/mnt

-> Success

As root, achieved by su -:

rnapier$ su -

Password:

root# mount -t smbfs smb://admin:admin@rat-win7/kace /tmp/mnt

-> Success

sudo:

rnapier$ sudo mount -t smbfs smb://admin:admin@rat-win7/kace /tmp/mnt

mount_smbfs: server rejected the connection: Authentication error

-> Fail

As root, achieved by su (no -):

rnapier$ su

Password:

root# mount -t smbfs smb://admin:admin@rat-win7/kace /tmp/mnt

mount_smbfs: server rejected the connection: Authentication error

-> Fail

robnapier wrote:

I'm seeing this poblem as well. The problem so far seems to be when uid!=euid, particularly when running under sudo.

That makes sense. It would explain why it worked under launchd.

Unfortunately, Apple takes a rather practical view of such things. I once filed an enhancement request to have Apple implement something like Windows' "Run as" instead of the convoluted instructions about how to enable the root user. People were always trying that and screwing up their systems. Apple's response to my request was something like "Why would you ever do that? Just use sudo."

I sincerely doubt the problem of using mount_smbfs in a sudo root context is ever going to get any attention from Apple. It was designed to be run in a user context.

http://www.opensource.apple.com/source/smb/smb-552.5/kernel/netsmb/smb_gss.c

...

/* use sysctl -w net.smb.fs.kern_ntlmssp=1 to set smbfs_kern_ntlmssp */

int smbfs_kern_ntlmssp = 0;

...

and normaly the status of (smbfs_kern_ntlmssp == 0) is true,

so, this results in that codes error = EAUTH; somewhere.

if you do

sysctl -w net.smb.fs.kern_ntlmssp=1

as root, root user's mount_smbfs will be success.