4

I have a recurring problem with mounting/un-mounting remote directories via SMB, however I don't know what triggers the problem nor how to resolve it.

Background:

After successfully mounting the directory via SMB and some time using it, the directory seems to unmount by itself. When this happens, I am unable to re-mount the directory until I restart my system.

If I don't restart the system and use the "Connect to Server" dialog to try to mount the directory via SMB, the dialog disappears as though the connection was successful, however nothing is mounted.

If I try to do the same thing with a parent directory (which is the root directory of the server), then the connection appears to be successful and prompts me to "Select the volumes you want to mount on 'xyz.server.name':" with a listing of directories. The directory that I previously mounted (which auto-unmounted) is listed, but is ghosted out and therefore unable to be selected.

When SSH-ing into the server, there does not appear to be any problem with accessing the directory.

This problem occurs for other remote directories as well (though I have not been able to test it on another server).

Also, when trying to reconnect under this scenario, Console reports the following issue:

"30/10/2014 11:48:20.520 am NetAuthSysAgent[3346]: smb_mount: mount failed to my.server.com/mydirectory, syserr = File exists"

Questions:

i) What is causing the directory/volume to be unmounted?

ii) How can I prevent the auto-unmount from happening?

iii) If an auto-unmount occurs, how can I re-mount the directory without restarting?

System details:

OS X 10.9.5

Retina, 15-inch, Early 2013

Server details:

Red Hat Enterprise Linux Server release 5.11 (Tikanga)

Kernel version 2.6.18-371.8.1.el5

Output of df:

Before problem:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899360656   75553192    93% 112484080    9444149   92%   /
devfs                                                    371         371          0   100%       644          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10486471008   82479408   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

After problem:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899350976   75562872    93% 112482870    9445359   92%   /
devfs                                                    373         373          0   100%       648          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10466951592  101998824   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Observations:

The mounted directories are still listed in /Volumes when viewed from the terminal, (i.e. 'ls /Volumes'), though this is not always the case, but both directories are inaccessible. They are not visible within Finder at all.

However, I am able to still access the content of one of the directories from Matlab, which was already within a subdirectory of this directory (its working directory). If I then move outside of the directory in Matlab (say, to my home directory), I am unable to return to it via the 'cd' command but instead need to press the back button within the file navigation toolbar and then everything is accessible again from within Matlab.

Improve this question
9
  • did you try to switch to cifs instead of smb2? maosxhints
    – klanomath
    Nov 5, 2014 at 18:29
  • 1
    That's a very old RHEL install. I have Samba4 running on Scientific Linux 6.5 (RHEL clone) without any issues at all.
    – miken32
    Nov 7, 2014 at 21:29
  • Sorry, meant to write more there. What version of Samba are you running? Do you get anything on the server side error log? Any network connectivity issues or computer sleeping that could be causing the disconnection?
    – miken32
    Nov 7, 2014 at 21:37
  • Is this a Finder, client or server problem. When your unmounting problem ocurs, is it possible to do cd /Volumes/josh from Terminal?
    – dan
    Nov 9, 2014 at 18:05
  • @klanomath yes, I have tried cifs, but it did not seem to work in my case.
    – Josh
    Nov 9, 2014 at 23:29

5 Answers 5

Reset to default
1

I'm going to put up an answer to question 3. Not sure the rest can be easily diagnosed.

"If an auto-unmount occurs, how can I re-mount the directory without restarting?"

Try diskutil umount /Volumes/josh and it should do the trick.

The "File exists" error is showing up because the mount point it wants to use is already present. Looks like the disk isn't actually unmounted, just that Finder can't see it. This is why Matlab can still access the files on it.

Improve this answer
2
  • 1
    This works as far as unmounting is concerned, but I am unable to remount the directory afterwards.
    – Josh
    Nov 9, 2014 at 23:26
  • @danielAzuelos, the OP states he can ssh into the host at any time.
    – CousinCocaine
    Nov 16, 2014 at 9:41
0

According to the Red Hat site, they don't support using SMB shares using the OS X Finder. Looks like you can still get at it using the Terminal, so that could be a workaround for now.

In regards to the random disconnect: It sounds like the share will connect initially, and then freak out after it realizes it's in the Mac environment. Looks to me like the share doesn't unmount correctly, and that's why you wouldn't be able to re-connect to it. It's actually still there, just not visible in Finder.

If you were to manually unmount the share using the Terminal, I'd expect it wouldn't be greyed out if you were to try and connect to it again.

A fix: Depending on how the Red Hat server was set up, you should be able to FTP into it. Mac has a few FTP GUIs that you can try out, or use the Terminal's ftp command.

Improve this answer
2
  • Yes, I am using FTP for file transfer when I have problems with SMB, however (as far I know) FTP doesn't allow me to utilise the files remotely within my local applications (e.g. Matlab). Transferring files just for editing/updating becomes cumbersome and error-prone.
    – Josh
    Nov 9, 2014 at 23:28
  • I'm assuming you don't have access to the RHEL server, correct? If you do, you should be able to use Netatalk to make an AFP share, and THAT should work just fine. Are you using a GUI like Filezilla? Or are you using the Terminal's ftp command to access the files? I've had pretty good luck using Filezilla (although I've never had to deal with Matlab). Unfortunately, I don't see a reliable workaround if you don't have access to the server. Maybe get in touch with the server manager and ask about Netatalk.
    – zomgdavidbowie
    Nov 9, 2014 at 23:36
0

What is causing the directory/volume to be unmounted?

Most probably a network connection instability which might be amplified by the use of the Automatic configuration which might switch from Ethernet to Airport trying to maintain your network connectivity.

To validate this hypothesis, use:

netstat -I
ping -c 90 -i 10 your_SMB_server
tail -f /var/log/system.log
...

How can I prevent the auto-unmount from happening?

If this netwok problem is confirmed, then fix it :):

  • change cable
  • change switch port
  • ask your network admin
  • ...

If an auto-unmount occurs, how can I re-mount the directory without restarting?

You can't if the unmount didn't terminate correctly. Some state information within your SMB kernel extension is corrupted (half modified) and can't be fixed in any other way than the correct termination of the pending unmount. If your connection was broken, I know of one uniq way to terminate a pending SMB unmount: shutdown of Mac OS X (I tried a kextunload which lead to a total failure).

You should absolutely avoid such a pending unmount to occur.

Improve this answer
0

The answer from miken32 didn't work for me, but got me on the right track. My problem was solved after unmounting all shares on the server in question (in your case "example.com").

So, using your case, diskutil umount /Volumes/josh isn't enough, because /Volumes/semantic still remains. You must unmount that one, too. After that, remounting should work (it did at least for me).

Bi the way, you don't have to use diskutil, instead you can execute

umount //[email protected]/josh

and

umount //[email protected]/semantic
Improve this answer
0

I have same problem, had it on 10.6.8 and now on 10.11. The cause is twofold: for one, share is supposed to unmount (e.g. on sleep), but it cannot because it is being (flagged as) used, so it dies and what is left is a folder in /Volumes which you could sometimes just delete and then remount. However in 10.11 it is invisible in Finder AFTER the share dies (see Finder preferences, they say Finder shows only active shares.

For the second, the flag that the files are in use is set by MatLab. Some times you can remove them by MatLab command fclose all and cd to some other place to free the share, some times you actually do use files (by editing .m script from the share). But often after a period of inactivity it goes in a dead lock: umount and diskutil unmount cannot release the share because "Resource busy" and MatLab cannot release its flags because the share is long gone.

I use macfusion, so there indeed is a mechanism for the share to die when sshfs looses connection to the server. Out of these three: Finder, MatLab and fuse, I would say the MatLab is evil, as other programs like BBedit never lock the share in such a deadly way. I often can remount only after I quit MatLab.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .