CIFS share mount errors
Troubleshoot accessing a windows XP shared folder from Fedora:
You are receiving the error:
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
1. Make sure Linux can ping the other box.
Run this command on the linux box to the IP of the windows box:
el@defiant /mnt $ ping 192.168.13.107
PING 192.168.13.107 (192.168.13.107) 56(84) bytes of data.
64 bytes from 192.168.13.107: icmp_req=1 ttl=128 time=0.366 ms
--- 192.168.13.107 ping statistics ---
44 packets transmitted, 44 received, 0% packet loss, time 42999ms
rtt min/avg/max/mdev = 0.178/0.227/0.366/0.038 ms
If you can't reach the box or connectivity is in and out, mount may complain.
2. Make sure a folder is actually shared on windows, follow these steps.
- Open the file browser to
C:\. - Create a new folder called
public. So you now have C:\public - Inside that folder, make a new text document called "testing.txt".
- Right click the folder
C:\publicand go to properties. - Click the sharing tab.
- Make sure: "Share this folder on the network" is checked. Note the share name: 'public'.
- Click ok. A little hand should appear underneath the folder, meaning it is shared.
The folder 'public' is now shared and you should be able to connect to it with Linux.
3. On Linux, mount the share with 'mount':
- Open a console and
suto root. make a directory
mkdir /mnt/windowsThis will be where you access the shared files.run the mount command which prompts for a password:
[root@defiant mnt]# mount -t cifs //192.168.13.107/eric /mnt/windows -o username=eric Password for eric@//192.168.13.107/public: ********** [root@defiant mnt]#The above command prompts you for a password, enter the correct password, an incorrect one will produce an error. If you are unsure of the password, you can change the password on the windows box under Control Panel -> User Accounts.
run the command
cd /mnt/windowsand runls. The contents of the drive are presented:[root@defiant windows]# ls testing.txt [root@defiant windows]#You have connected to the windows drive.
4. Connect to the shared drive with the konqueror or linux file browser:
- Open your file browser, in my case konqueror.
- In the file location bar, enter
smb://192.168.13.107/publicand press enter. - You may be presented with a username and password login box. Enter the username and password of the windows box described at the top of this post.
- Congratulations you are connected to the shared folder.
TROUBLESHOOTING, if the above doesn't work.
Step 1: Have you tried restarting both computers
Reboot both of your computers. After that, make sure all your windows updates are done. Make sure Linux has its software updates taken care of as well. Reboot after updates.
Step 2: Review your Firewalls, ZoneAlarms, and other Security Software
A piece of software designed to protect your computer from viruses, malware or evils on the internet might be blocking your file sharing attempt. Windows firewall might be in a paranoid mode. Although it is unlikely Windows Firewall is to blame, turn it off temporally to verify it's not the problem. (don't leave it off).
Acquire a list of all the security software that might be set to paranoid mode. Windows Firewalls, 3rd party firewalls, ZoneAlarms, Antiviruses, Kaspersky, AVG, or anything else that claims to protect you from viruses/malware/evil. You will need to review these and either turn them off temporally, or open a white list through them for your IP address.
Step 3: Acquire clues from security software.
ZoneAlarm keeps a log of all folder share events and attempts, go to Overview->alerts and logs. And see a list of all your failed attempts. The same is possible for other software. In that case, it's protecting you from you.
Step 4: Suspect problems in the router or local area network itself
Maybe the router, wireless bridges, dumb hubs, or other network device has some directive shenanigan in it by blocking your shared folder connect attempt. The router or device itself might be blocking a port or has something in restrictive mode. Has anyone been fooling around with it lately? Try setting the router back to default everything and trying again.
Step 5: Make sure your local area network is simple and correct.
Are both your computers connecting to the same router? Perhaps one is connected to a crappy netgear wireless bridge and the other to a router? Simplify the network by having all computers connect to one router. Restart the routers and the internet, try again.
Step 6: Still not working. Isolate the defective unit.
It's time to herd cats and isolate the defective unit. Prove the windows box is not sharing your file by connecting to the share with a different computer. Get a friends windows laptop, or apple product and connect it to your network and see if they can access the share. If they can't, the windows box has a problem, if they can, the Linux box has the problem.
Step 7: Suspect the firewall on Linux
Take note of any special security alarm or special firewall software on Linux. Run system-config-firewall and make sure smb is checked. Check to make sure Linux is not preventing your mount. Create a smb share on another Linux box, and try to connect to that.
If none of this works. Use the nuclear option, re install both operating systems and start over at the top. This is rocket surgery.
Try:
mount -t cifs -v //NAS_SERVER/public/ /mnt/ -o username=user,password=pass,sec=ntlm
The key is sec=ntlm
Adding more possible solutions to this problem
This error message isn't very descriptive, but what it means is the operation has timed out. There are numerous possible reasons for this, and while researching this problem, I ran across some solutions that haven't been mentioned on this thread yet.
1.) Ambiguous Network
It isn't often mentioned in the various solutions you can find to this problem online, but the server you are connecting to has to be on the same subnet as your local machine. This problem arose for me because I had both the wired and wireless connections enabled, and determining which subnet the device belonged to was ambiguous, as the two connections aren't the same network. Disabling Wifi fixed the problem instantly. I stumbled upon this solution while reading Das Werkstatt:
[SOLUTION]
In my case, the DFS share was on a storage in a different subnet. I added a network alias (eth0:1) with an IP in that storage-subnet and then it worked.
I would have expected something like "no route to host" instead of the cryptic "error (115): Operation now in progress"...
Well, can't have it all ;)
Source: http://www.das-werkstatt.com/forum/werkstatt/viewtopic.php?f=7&t=2074
2.) Newlines at the end of the credentials file
Credentials files are useful if you have special characters such as the comma , in your password. It can be referenced in the options like so:
mount -t cifs //remote /mnt/local -o credentials=/path/to/cifs.credo
The file is formatted with sh-style variable declaration:
username=me
password=mypassword
domain=mydomain
If you are using a credentials file, make sure there are no newline characters at the end, or it will timeout while trying to parse the credentials file:
...
domain=mydomain
<empty line>
3.) Trying to mount a specific directory rather than the actual share point
If the specific directory you need is a subdirectory of the share, you won't be able to mount that folder directly. Attempting to do so results in a couple of different errors, this being one of them.
Instead, mount the share point itself, and then add a symbolic link to the subdirectory you need:
~> mkdir /mnt/local
~> sudo mount -t cifs //remote /mnt/local
~> ln -s /mnt/local/path/to/my-folder /mnt/my-folder
This way, you get the same result as mounting the subdirectory itself without having to drill down to it every time.