Produces the following command on Ubuntu 64bit on VMWare:
mount /dev/sda1 /newroot
cd /newroot
mkdir old-root
pivot_root . old-root
I get an error that I do not understand
pivot_root: device or resource busy
Any ideas?
I saw the same error when the new root directory is a plain directory. When the new root is a mount, it will be ok. A bind mount of a directory is ok too. Also need to make sure the root directory permission is 0755, and owned by the root user.
The related answer states that you need to umount /proc first. I do not see the same.
The host ubnutu is 16.04 and it pivots into 18.04. Used unshare -m -p -f /bin/bash, followed by pivot_root . old_root. The -f is necessary to avoid a memory allocation error.
Related
I'm trying to make a fast reboot to the other Linux system. First step is kernel loading, I make it with
sudo kexec --append='$(cat /proc/cmdline)' -l new_kernel.img --reuse-cmdline
sudo kexec -e
It works fine, but loads only kernel, not entire system.
How can I mount an *.img file with OS resources, located at USB as /? Preferable during kernel loading, but afterwards mount is still suitable. *.img format is not necessary, it can be unpacked before
As stark said, pivot root() was the call I was searching for. Commands to make a USB located at /dev/sdb1 a root directory:
sudo -s
mkdir /newroot
mount /dev/sdb1 /newroot
cd /newroot
mkdir oldroot
pivot_root . oldroot/
switch_root() deletes all files at the previous root dir, also there are few other differences, this answer might be useful
I'm trying to get a Linux VM using Virtual Box, Virtual Box Guest Additions, and Vagrant running and to mount a folder on my Windows 7 machine. I've tried the suggestions in this question, but still get the same error.
I'm running the following versions:
Virtual Box: 4.3.18 r96516
Virtual Box Guest Additions: 4.3.18
Vagrant: 1.6.5
Vagrant Plug-ins:
vagrant-login: 1.0.1
vagrant-share: 1.1.2
vagrant-vbguest: 0.10.0
When I run vagrant reload I get the following error:
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:
mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3`,
nolock,vers=3,udp,noatime core /tbm
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant`,nolock,vers=3,udp,noa
time core /tbm
The error output from the last command was:
stdin: is not a tty
unknown mount option `noatime'
valid options:
rw mount read write (default)
ro mount read only
uid =<arg> default file owner user id
gid =<arg> default file owner group id
ttl =<arg> time to live for dentry
iocharset =<arg> i/o charset (default utf8)
convertcp =<arg> convert share name from given charset to utf8
dmode =<arg> mode of all directories
fmode =<arg> mode of all regular files
umask =<arg> umask of directories and regular files
dmask =<arg> umask of directories
fmask =<arg> umask of regular files
I've tried un-installing, installing, updating the vagrant-vbguest plugin:
vagrant plugin install vagrant-vbguest
I've tried running the following command after running vagrant ssh, but still get the same error message:
sudo ln -s /opt/VBoxGuestAdditions-4.3.18/lib/VBoxGuestAdditions /usr/lib/VBoxGuestAdditions
I'm not super familiar with mount options, but I tried executing your command in a similar VM I'm running and got the same error regarding the noatime option.
I read through the documentation (man 8 mount) which states somewhere after line 300 or so, in the FILESYSTEM INDEPENDENT MOUNT OPTIONS that: Some of these options are only useful when they appear in the /etc/fstab file.
I suspect this is your problem. I edited my /ect/fstab file to change one of my mounts to /dev/mapper/precise64-root / ext4 noatime,errors=remount-ro 0 1 this option and then ran the following:
sudo mount -oremount /
vagrant#precise64:~$ mount
/dev/mapper/precise64-root on / type ext4 (rw,noatime,errors=remount-ro)
...
I edited the file again to remove the option and:
vagrant#precise64:~$ sudo mount -oremount /
vagrant#precise64:~$ mount
/dev/mapper/precise64-root on / type ext4 (rw,errors=remount-ro)
...
I don't know if you're providing these mount commands or if they come from a plugin, but it seems like (at least in your environment), the option works fine, but can't be specified on the command line.
Environment is in virtual box,ubuntu 12.04. It has 2 disks, /dev/sda1 and /dev/sdb1 are both ext4 type filesystem.
Since /dev/sdb1 is add after system installed, so I want to mount it manually. I'd try this command:
sudo mount -o user,defaults /dev/sdb1 ~/project
No errors report. Then I get mount info by mount:
/dev/sdb1 on /home/igsrd/project rw,noexec,nosuid,nodev
But when I ls -l to see /home/igsrd I found its permission is still belongs root, so I can't touch anything in it. Why it still belongs root?
I have another machine running ubuntu 12.04,too. I mount another partition with same option will be fine, correct permission(ownership). Are any differences between them?
*nix permissions on a filesystem that supports them natively, e.g. ext4, will be maintained regardless of how it is mounted when using a proper filesystem driver, e.g. the native ext4 driver built into Linux.
Why don't you just (while still root) do this:
chown -R <your-user-name> ~<your-user-name>/project
?
I'd like to mount a remote directory through sshfs on my Debian machine, say at /work. So I added my user to fuse group and I run:
sshfs user#remote.machine.net:/remote/dir /work
and everything works fine. However it would be very nice to have the directory mounted on boot. So I tried the /etc/fstab entry given below:
sshfs#user#remote.machine.net:/remote/dir /work fuse user,_netdev,reconnect,uid=1000,gid=1000,idmap=user 0 0
sshfs asks for password and mounts almost correctly. Almost because my regular user has no access to the mounted directory and when I run ls -la /, I get:
d????????? ? ? ? ? ? work
How can I get it with right permissions trough fstab?
Using option allow_other in /etc/fstab allows other users than the one doing the actual mounting to access the mounted filesystem. When you booting your system and mounting your sshfs, it's done by user root instead of your regular user. When you add allow_other other users than root can access to mount point. File permissions under the mount point still stay the same as they used to be, so if you have a directory with 0700 mask there, it's not accessible by anyone else but root and the owner.
So, instead of
sshfs#user#remote.machine.net:/remote/dir /work fuse user,_netdev,reconnect,uid=1000,gid=1000,idmap=user 0 0
use
sshfs#user#remote.machine.net:/remote/dir /work fuse user,_netdev,reconnect,uid=1000,gid=1000,idmap=user,allow_other 0 0
This did the trick for me at least. I did not test this by booting the system, but instead just issued the mount command as root, then tried to access the mounted sshfs as a regular user.
Also to complement previous answer:
You should prefer the [user]#[host] syntax over the sshfs#[user]#[host] one.
Make sure you allow non-root users to specify the allow_other mount option in /etc/fuse.conf
Make sure you use each sshfs mount at least once manually while root so the host's signature is added to the .ssh/known_hosts file.
$ sudo sshfs [user]#[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
REF: https://wiki.archlinux.org/index.php/SSHFS
Also, complementing the accepted answer: there is a need that the user on the target has a right to shell, on target machine: sudo chsh username -> /bin/bash.
I had a user who had /bin/false, and this caused problems.
I have a CIFS share mounted on a Linux machine. The CIFS server is down, or the internet connection is down, and anything that touches the CIFS mount now takes several minutes to timeout, and is unkillable while you wait. I can't even run ls in my home directory because there is a symlink pointing inside the CIFS mount and ls tries to follow it to decide what color it should be. If I try to umount it (even with -fl), the umount process hangs just like ls does. Not even sudo kill -9 can kill it. How can I force the kernel to unmount?
I use lazy unmount: umount -l (that's a lowercase L)
Lazy unmount. Detach the filesystem
from the filesystem hierarchy now, and
cleanup all references to the
filesystem as soon as it is not busy
anymore. (Requires kernel 2.4.11 or
later.)
umount -a -t cifs -l
worked like a charm for me on CentOS 6.3. It saved me a server reboot.
On RHEL 6 this worked:
umount -f -a -t cifs -l
This works for me (Ubuntu 13.10 Desktop to an Ubuntu 14.04 Server) :-
sudo umount -f /mnt/my_share
Mounted with
sudo mount -t cifs -o username=me,password=mine //192.168.0.111/serv_share /mnt/my_share
where serv_share is that set up and pointed to in the smb.conf file.
I had this issue for a day until I found the real resolution. Instead of trying to force unmount an smb share that is hung, mount the share with the "soft" option. If a process attempts to connect to the share that is not available it will stop trying after a certain amount of time.
soft Make the mount soft. Fail file system calls after a number of seconds.
mount -t smbfs -o soft //username#server/share /users/username/smb/share
stat /users/username/smb/share/file
stat: /users/username/smb/share/file: stat: Operation timed out
May not be a real answer to your question but it is a solution to the problem
There's a -f option to umount that you can try:
umount -f /mnt/fileshare
Are you specifying the '-t cifs' option to mount? Also make sure you're not specifying the 'hard' option to mount.
You may also want to consider fusesmb, since the filesystem will be running in userspace you can kill it just like any other process.
Try umount -f /mnt/share. Works OK with NFS, never tried with cifs.
Also, take a look at autofs, it will mount the share only when accessed, and will unmount it afterworlds.
There is a good tutorial at www.howtoforge.net
I had a very similar problem with davfs. In the man page of umount.davfs, I found that the -f -l -n -r -v options are ignored by umount.davfs. To force-unmount my davfs mount, I had to use umount -i -f -l /media/davmount.
umount -f -t cifs -l /mnt &
Be careful of &, let umount run in background.
umount will detach filesystem first, so you will find nothing abount /mnt. If you run df command, then it will umount /mnt forcibly.
Approaching this problem sideways:
If you can't unmount because the filesystem is busy, is your ssh/terminal session cd'd into the mount directory, therefore making the filesystem busy?
For me, the solution was to cd into my home, then sudo umount worked flawlessly.
cd ~
umount /path/to/my/share
I would post this as a comment, but I have insufficient reputation. Hoping to spare someone else the forehead slap.
I experienced very different results regarding unmounting a dead cifs mount and found several tricks to bypass the problem temporarily.
Let's start with the mountpoint command. It can be useful to analyze the status of a mount:
mountpoint /mnt/smb_share
Usually it returns is a mountpoint or / is not a mountpoint.
But it can even return:
No such device
Transport endpoint is not connected
<nothing / stale>
For every result expect of is not a mountpoint there is a chance of unmounting.
You could try the usual way:
umount /mnt/smb_share
or force mode:
umount /mnt/smb_share -f
But often the force does not help. It simply returns the same nasty device is busy message.
Then the only option is to use the lazy mode:
umount /mnt/smb_share -l
BUT: This does not unmount anything. It only "moves" the mount to the root of the system, which can be seen as follows:
# lsof | grep mount | grep cwd
mount.cif 3125 root cwd unknown / (stat: No such device)
mount.cif 3150 root cwd unknown / (stat: No such device)
It is even noted in the documentation:
Lazy unmount. Detach the filesystem from the file hierarchy
now, and clean up all references to this filesystem as soon
as it is not busy anymore.
Now if you are unlucky, it will stay there forever. Even killing the process probably does not help:
kill -9 $pid
But why is this a problem? Because mount /mnt/smb_share does not work until the lazy unmounted path is really cleaned up by the Linux Kernel. And this is even mentioned in the documentation of umount. "lazy" should only be used to avoid a long shutdown / reboot times:
A system reboot would be expected in near future if you’re
going to use this option for network filesystem or local
filesystem with submounts. The recommended use-case for
umount -l is to prevent hangs on shutdown due to an
unreachable network share where a normal umount will hang due
to a downed server or a network partition. Remounts of the
share will not be possible.
Workarounds
Use a different SMB version
If you still have hopes that the lazy unmounted path will ever be not busy anymore and cleaned up by the Linux Kernel or you can't reboot at the moment, then you are maybe lucky and your SMB server supports different protocol versions. By that we can use the following trick:
Lets say you mounted your share as follows:
mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw
By that Linux automatically tries the maximum support SMB protocol version. Maybe 3.1. Now, you can force this version and it won't mount as expected:
mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=3.1
But then simply try a different version:
mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=3.0
or maybe 2.1:
mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=2.1
Change the IP of the SMB server
If you are able to change the IP address or add a second IP to your SMB server, you can use this to mount the same server.
Dirty: Forward the traffic
Lets say the SMB server has the IP address 10.0.0.1 and the mount is really dead. Then create this iptables rule:
iptables -t nat -A OUTPUT -d 10.0.0.250 -j DNAT --to-destination 10.0.0.1
Now change your mount rule accordingly, so it mounts the samba server through IP 10.0.0.250 instead of 10.0.0.1 and voila, its mounted without server reboot. Dirty, but it works. PS This rule does not survive a reboot, so you should mount the SMB server manually and leave the /etc/fstab as usual.
More debugging
If you want to check if samba connection itself is theoretically working, you could try to list all SMB shares of the server through SMB3 as follows:
smbclient //smb.server -U "smb_user" -m SMB3 -L
or to view the content of a share with SMB1:
smbclient //smb.server -U "smb_user" -m NT1 -c ls
On RHEL 6 this worked for me also:
umount -f -a -t cifs -l FOLDER_NAME
A lazy unmount will do the job for you.
umount -l <mount path>