I am writing an initramfs, executed in busybox, in which I mount a partition using those commands:
/bin/busybox mount -n -t proc proc /proc
mount -n -t devtmpfs devtmpfs /dev
mount -n -t sysfs sysfs /sys
mount -n -t tmpfs inittemp /mnt
mkdir /mnt/saved
mount -n -t "${rootfstype}" -o "${rootflags}" ${device} /mnt/saved
But when the system starts up, I have this error:
mount: mounting /dev/mmcblk0p2 on /mnt/saved failed: No such file or directory
I know that when the device is not found, there is a message like Device does not exist, so I think the problem is coming from the directory /mnt/saved that is not correctly created yet.
I tried adding an ls -l /mnt after the mkdir to check that the directory is correctly created, but most of the time, if I do so, the error disappears. So I though the problem might be synchronization problem (of the tmpfs, weird!) So I tried some other things like creating a dummy file in the directory to force a kind of synchronisation. This works, but is a dirty workaround and I want to find the real cause of the problem to build a clean solution.
By the time I was writing my question, I finally found the solution by myself… I post it anyway just in case somebody is stuck like me.
Actually, the mount command of busybox does not show a message about device, if it cannot find it, but always show No such file or directory.
My problem was actually coming from the root device which was not ready yet, and so not in the /dev directory yet. In order to make it work correctly, I simply added this line before the mount:
while ${rootwait} && ! [ -b "${device}" ]; do sleep 1; done
I am trying to mount a file that will act as a read/write HFS+ filesystem. I am using arch linux based distro so I installed hfsprogs and hfsutils. In debian based distros hfsprogs should be enough.
I created a 8G file like this:
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1000*8000]
Then I did the formatting:
mkfs.hfsplus -v TestImg test.img
After that when I try to mount the file I get:
mkdir /tmp/sun
sudo mount -t hfsplus -o loop,rw,offset=0 test.img /tmp/sun
mount: /tmp/sun: mount failed: Operation not permitted
Parted shows that offset it ok:
sudo parted -m test.img unit B print
1:0B:8191999999B:8192000000B:hfs+::;
I also tried to use fdisk with the file creating sun partition table but that did not help either. Can you help me please with creating HFS+ rw filesystem as a file?
I used loop device inappropriately.
The correct steps are:
Create file
dd if=/dev/zero of=test.img bs=100MB count=10 seek=$[10*8]
Create blocked device mapped to that file:
losetup -fP test.img
At this point blocked device /dev/loop0 got created.
Create filesystem:
mkfs.hfsplus test.img
Mount to your folder
mount -o rw,loop /dev/loop0 /tmp/loop_test
I have the following in my /etc/fstab file:
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
sv-01:/mnt/UEF/home/user/Videos/complete /home/user/Videos nfs defaults,noauto,user 0 0
and when I issue the command sudo mount -a -v, I get the following output
mount: proc already mounted on /proc
mount: /dev/mmcblk0p1 already mounted on /boot
nothing was mounted
but when I copy paste the above segment of code and issue the below command, the folder mounts perfectly.
sudo mount sv-01:/mnt/UEF/home/user/Videos/complete /home/user/Videos
What could possibly be causing this?
You specified "noauto" parameter for sv-01:/mnt/UEF/home/user/Videos/complete.
From mount manual:
mount -a [-t type] [-O optlist]
(usually given in a bootscript) causes all filesystems mentioned in
fstab (of the proper type and/or having or not having the proper
options) to be mounted as indicated, except for those whose line
contains the noauto keyword. Adding the -F option will make mount
fork, so that the filesystems are mounted simultaneously.
I'm trying to install riak on my OSX 10.8.5, but when using the command riak-admin test it always fail. I can't find a solution for it!
Also using sudo riak-admin test doesn't help it.
I have installed riak(1.4.2) through brew.
>riak start
!!!!
!!!! WARNING: ulimit -n is 256; 4096 is the recommended minimum.
!!!!
>riak ping
pong
>riak-admin test
Failed to write test value: {error,timeout}%
I have installed riak(1.4.2) precompiled tarball using wget
>curl -O http://s3.amazonaws.com/downloads.basho.com/riak/1.4/1.4.2/osx/10.8/riak-1.4.2-OSX-x86_64.tar.gz
>tar xzvf riak-1.4.2-osx-x86_64.tar.gz
>cd riak-1.4.2
>bin/riak start
!!!!
!!!! WARNING: ulimit -n is 256; 4096 is the recommended minimum.
!!!!
>bin/riak ping
pong
>bin/riak-admin test
Failed to write test value: {error,timeout}%
I have install riak(1.4.1) precompiled tarball using wget
>curl -O http://s3.amazonaws.com/downloads.basho.com/riak/1.4/1.4.1/osx/10.8/riak-1.4.1-OSX-x86_64.tar.gz
>tar xzvf riak-1.4.1-osx-x86_64.tar.gz
>cd riak-1.4.1
>bin/riak start
!!!!
!!!! WARNING: ulimit -n is 256; 4096 is the recommended minimum.
!!!!
>bin/riak ping
pong
>bin/riak-admin test
Failed to read test value: {error,{insufficient_vnodes,0,need,1}}%
Solution
Following this procedure http://docs.basho.com/riak/... solved my issue.
It has to do with the Open Files Limit on mac OSX.
Before
To check the current limits on your Mac OS X system, run:
>launchctl limit maxfiles
maxfiles 256 unlimited
Edit (or create) /etc/launchd.conf
Edit (or create) /etc/launchd.conf and increase the limits. Add lines
that look like the following (using values appropriate to your
environment):
limit maxfiles 16384 32768
Restart the system
Save the file, and restart the system for the new limits to take
effect. After restarting, verify the new limits with the launchctl
limit command:
>launchctl limit maxfiles
maxfiles 16384 32768
I am trying
sudo mount -t cifs //<server>/<share> -o username=user#domain,password=**** /mnt/<mountpoint>
error message:
mount: wrong fs type, bad option, bad superblock on //server/share,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
The syslog has
CIFS VFS: cifs_mount failed w/return code = -22
I am able to mount the same share on another centos system. I can ping the server, mount point directory has been created.
I ran into this problem when using a host name and solved it by using an IP address. E.g.:
use
mount -t cifs //192.168.1.15/share
rather than
mount -t cifs //servername/share
Another possible solution is to install
cifs-utils
.
Ah, the dreaded -22. Basically this seems to be used as a catchall for "something didn't work", although technically it's referred to as an invalid argument.
The client does IMHO a very poor job of telling you the actual problem. (This may not be its fault - it doesn't always have access to that information).
However -- have you checked the logs on the server/machine you are connecting to?
I was connecting to an OS X samba server, and learned from what I found in the logs there that it was necessary to specify additional options under -o as follows:
nounix,sec=ntlmssp
Among the things these settings enable are "allow long names", and "ignore UNIX filename endings"...sec is to specify security flags.
Another possibility is that you're trying to access a filesystem of a type that mount.cifs can't actually handle.
For RHEL/Centos install package - "cifs-utils"
Maybe move the target?
sudo mount -t cifs -o username=user#domain,password=**** //<server>/<share> /mnt/<mountpoint>
Or maybe this solution? (Ubuntu, Debian methods)
sudo apt-get install smbfs
Or for CentOS, RedHat, Fedora try:
sudo yum install samba-client
I had a similar issue on Ubuntu 12.04 with the "mount" package (version 2.20.1-1ubuntu3).
It happened when I was trying to mount the server share using its hostname rahter than its IP.
Another way to solve the issue on Ubuntu was to install the cifs-utils package. That way I could also mount the samba share using the exact same command line (or fstab) but with hostname.
sudo mount -t cifs //hostname/share -o username=user,password=pwd /mnt/share
Just did a clean install of Ubuntu 12.04 LTS and got this trying to hook up my Linux HTPC.
Solved it by running: sudo apt-get install cifs-utils then remounting it.
CIFS returns code "-22" in many cases (not only invalid arguments).
For me installing keyutils did the trick:
apt-get install keyutils
My distribution is "Ubuntu 14.04.2 LTS".
I figured this out by increasing the logging verbosity of CIFS:
echo 7 > /proc/fs/cifs/cifsFYI
# disable again via:
#echo 0 > /proc/fs/cifs/cifsFYI
Documentation on the bitmask ("7") for cifsFYI can be found here: https://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README
After trying to mount once more dmesg included more helpful information:
Dec 7 12:34:20 pc1471 kernel: [ 5442.667417] CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
Another maybe helpful link:
http://vlkan.com/blog/post/2015/01/08/smb-mount-troubleshoot/
I have Ubuntu Server 12.10 x64 installed as a VMware VM, running on OS X 10.8 (Mountain Lion).
On the Mac, in SYSTEM PREFERENCES > SHARING > FILE SHARING (on), I added a folder to share. For my tests, I created a new folder within my Public folder called "ubuntu".
In Ubuntu, I issued the following commands:
sudo mkdir /media/target
sudo mount.cifs //10.0.20.3/ubuntu /media/target -o username=davidallie,nounix,sec=ntlmssp,rw
Ubuntu prompted me for the password and, once entered, mounted the folder. I then ran:
df -H
which allowed me to verify the mounts and mount-points.
This has recently manifested thanks to a kernel bug in v5.18.8+, I was able to reproduce on v5.18.9 and v5.18.11.
Here is the relevant ticket on kernel.org, quote:
it appears that kernel 5.18.8 breaks cifs mounts on my machine. With
5.18.7, everything works fine. With 5.18.8, I am getting:
$ sudo mount /mnt/openmediavault/
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel
log messages (dmesg)
The relevant /etc/fstab line is:
//odroidxu4.local/julian /mnt/openmediavault cifs
credentials=/home/julas/.credentials,uid=julas,gid=julas,vers=3.1.1,nobrl,_netdev,auto
0 0
Here is the offending commit, and here is the fix, which applies cleanly to v5.18.11. The cause is, from what I understand, a bug in old versions of the samba server in the negotiation protocol.
If this is your issue, you can:
patch your kernel yourself;
downgrade to v5.18.7;
switch to an LTS kernel;
use the userspace (and also really slow and awful) gvfs-smb;
upgrade the samba version on your server; or
add vers=2.0 to the mount.cifs options in /etc/fstab.
Note that while I haven't tried the last one personally, the venerable #SEBiGEM has confirmed in the comments that it works for v5.18.10.
Note also that I didn't try upgrading samba on the server at all because I hate touching the box it's running on - every time I upgrade anything everything breaks. Doing so might also not be an option for those with NAS appliances.
As a personal sidenote, it's a little sad that so many different things can cause -22. My answer is correct, but very very niche and specific to this point in time. I imagine in a month it will simply be useless noise.
Just experience the problem on RHEL 5. You don't need to install the samba suite, just the samba-client and any dependencies.
Maybe it's too late, but simplest solution described in kernel bug 50631:
in the latest code, unc mount parameter in mandatory. Modified command works for me:
sudo mount -t cifs //<server>/<share> -o username=user#domain,password=****,unc=\\\\<server>\\<share> /mnt/<mountpoint>
Try run the comamnd:
$modinfo cifs
filename: /lib/modules/3.2.0-60-virtual/kernel/fs/cifs/cifs.ko
version: 1.76
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French <sfrench#us.ibm.com>
srcversion: 9435BBC2F61D29F06643803
depends:
intree: Y
vermagic: 3.2.0-60-virtual SMP mod_unload modversions 686
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int)
parm: cifs_max_pending:Simultaneous requests to server. Default: 32767 Range: 2 to 32767. (int)
parm: echo_retries:Number of echo attempts before giving up and reconnecting server. Default: 5. 0 means never reconnect. (ushort)
parm: enable_oplocks:Enable or disable oplocks (bool). Default:y/Y/1 (bool)
If your getting any error then cifs is not installed. Just check with your admin. I thought it helps out.
Adding the option vers=3.0 to the mount command worked for me: sudo mount -t cifs -v <src> <dst> -o ...,vers=3.0,...
You need to install cifs-utils first , just as follows:
sudo yum install cifs-utils
I know this is old, but on older cifs-utils versions, you may have to add the following two lines to /etc/request-key.conf
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
Workaround without installing additional packages (cifs-utils adds another 81mb in Debian Stretch):
$ FILESERVER_IP=$(getent hosts myfileserver.com | awk '{ print $1 ; exit }')
$ sudo mount -t cifs //${FILESERVER_IP}/<share> -o username=user#domain,password=**** /mnt/<mountpoint>
Many answers, but wasn't work for me.
Solution:
My NAS didn't support Samba 3.0, on which my mount switch automatically.
So I downgraded smb version:
mount -t cifs //192.168.0.2/Share -o rw,vers=1.0,username=*****,password=******* /media/1
It's work.