ie the partition of interest is already mounted as read-only.the partition need to be mounted as a rw enabled partition for executing particular lines of script alone.After that the partition should go to it's previous state of read only.
Question is for QNX operating system. And correct way to remount partition as read/write can be done using below command.
mount -uw /
To remout a partition read-write:
mount /mnt/mountpoint -oremount,rw
and to remout read-only
mount /mnt/mountpoint -oremount,ro
you may be interested in remount option.
for example, this command is widely used in rooted androids.
mount -o remount,rw /system
mount -o remount,ro /system
mount(8) - Linux man page
Filesystem Independent Mount Options
remount
Attempt to remount an already-mounted filesystem. This is commonly used to change the mount flags for a filesystem, especially to make a readonly filesystem writeable. It does not change device or mount point.
The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.
mount -o remount,rw /dev/foo /dir
After this call all old mount options are replaced and arbitrary stuff from fstab is ignored, except the loop= option which is internally generated and maintained by the mount command.
mount -o remount,rw /dir
After this call mount reads fstab (or mtab) and merges these options with options from command line ( -o ).
Related
I moved my EFI partition which caused me to enter emergency mode on reboot.
mount -a confirmed fstab had the the UUID of the old partition...it wasn't mounting and that caused emergency mode.
You can't do ANY of the standard remount,rw tricks that normally work... it will always give you an error message the mount doesn't work
Sure, I could start from the USB stick and edit /etc/fstab, but isn't there an easier way?
This question has been around for 10 years and most people answer with a remount as rw, but that always fails.
The clever way is simply mount the / partition on /mnt like:
mount /dev/sda1 /mnt
This mounts it read-write and you just edit /mnt/etc/fstab to change the new UUID for your partition which you can get from either blkid or ls -lha /dev/disk/by-uuid
However, the readonly filesystem will NOT see your changes, so you think you've failed. You'll look at /etc/fstab and it will appear unchanged (at least under btrfs it looks unchanged).
However, when you reboot, you are back in business.
I re-sized my EFI partition down to 260MB, but had to remove it to do that which causes the UUID to change. Just changing the /etc/fstab with the new UUID is all that you need to do so you don't run into trouble. Best to do that when you move the partition, rather than after the fact.
I have RHEL 7.9 installed and here is what I did to edit the fstab after copying from one machine to another using scp.
mount -o remount,rw /dev/sda2 #sda2 is where my root directory is located.
I was then able to open in vim and save the UUID changes I had to make. Worked like a charm.
Run the following commands on linux (4.4.59 and 4.9.8 are tested) will fail:
mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc
and there is a error message in dmesg:
overlayfs: maximum fs stacking depth exceeded
Why can't /proc be a layer of a overlay file system?
If I replace /proc with /dev or /sys, it mounts without issue, so it seems there is something special with /proc.
P.S. The use case is creating a safer chroot environment, I want to make /dev, /sys and /proc read-only in chroot.
I use rsync for automatic periodic syncing of the home folder (root user) in a linux server that is used by several people. A service that users need is the possibility of mounting remote directories through sshfs. However, when there is an sshfs mount, rsync fails giving the following messages
rsync: readlink_stat("/home/???/???") failed: Permission denied (13)
IO error encountered -- skipping file deletion
...
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
Because of this error, the automated sync does not work as expected, in particular due to skipping the file deletion and a non-zero exit code. The sync is only necessary for the file system where home is mounted, so the wanted behavior is that the sshfs mounts be ignored. The -x / --one-file-system rsync option does not resolve it.
This problem is clearly explained in https://www.agwa.name/blog/post/how_fuse_can_break_rsync_backups . The follow-up article (https://www.agwa.name/blog/post/easily_running_fuse_in_an_isolated_mount_namespace) proposes a solution, though not an acceptable one because fuse mounts are only visible to the process created the mount.
I am looking for a solution that does not affect sshfs usability and is transparent for the users.
The problem is that FUSE denies stat access to other users, including root. Rsync requires stat access on all source files and directories specified. But when an rsync process owned by another user stats a FUSE mount-point, FUSE denies that process access to the mount-point's attributes, causing rsync to throw the said "permission denied" error. Mauricio Villega's solution works by telling rsync to skip FUSE mount-points listed by the mount command. Here is another version of Villega's solution that specifies a white-list of filesystem types using the findmnt command. I chose ext3 and ext4 but you may add other types as needed.
#!/bin/sh
# Which paths to rsync (note the lack of trailing slash tells rsync to preserve source path name at destination).
SOURCES=(
/home
)
# Which filesystem types are supported.
FSTYPES=(
ext3
ext4
)
# Rsync each source.
for SOURCE in ${SOURCES[#]}; do
# Build exclusion list (array of "--exclude=PATH").
excludedPaths=$(findmnt --invert --list --noheadings --output TARGET --types $(IFS=',';echo "${FSTYPES[*]}"))
printf -v exclusionList -- "--exclude=%s " ${excludedPaths[#]}
# Rsync.
rsync --archive ${exclusionList[#]} --hard-links --delete --inplace --one-file-system ${SOURCE} /backup
done
Note that it builds the exclusion list inside the loop to address a fundamental problem with this solution. That problem is due to rsync'ing from a live system where a user could create new FUSE mount-points while rsync is running. The exclusion list needs to be updated frequently enough to include new FUSE mount-points. You may divide the home directory further by each username by modifying the SOURCES array as shown.
SOURCES=(
/home/user1
/home/user2
)
If you are using LVM, an alternative solution is rsync from an LVM snapshot. An LVM snapshot provides a simple (e.g., no FUSE mount-points) and frozen view of the logical volume it is linked to. The downside is that you must reserve space for the LVM snapshot's copy-on-write (COW) activity. It is crucial that you discard the LVM snapshot after you are done with it; otherwise the LVM snapshot will continue to grow in size as modifications are made. Here is a sample script that uses LVM snapshots. Note that it does not need to build an exclusion list for rsync.
# Create and mount LVM snapshot.
lvcreate --extents 100%FREE --snapshot --name snapRoot /dev/vgSystem/lvRoot
mount -o ro /dev/mapper/snapRoot /root/mnt # Note that only root has access to this mount-point.
# Rsync each source.
for SOURCE in ${SOURCES[#]}; do
rsync --archive --hard-links --delete --inplace --one-file-system /root/mnt/${SOURCE} /backup
done
# Discard LVM snapshot.
umount /root/mnt
lvremove vgSystem/snapRoot
References:
"How FUSE Can Break Rsync Backups"
This error does not appear if the fuse mount points are excluded in the rsync command. Since it is an automated sync, the mount command can be used to obtain all fuse mount points. The output of the mount command may differ depending on the system, but in a debian jessie sshfs mounts appear as USER#HOST:MOUNTED_DIR on /path/to/mount/point type fuse.sshfs (rw,...). A simple way to automate the exclusion of fuse mounts in bash+sed is the following
SOURCE="/home/"
FUSEEXCLUDE=( $( mount |
sed -rn "
/ type fuse/ {
s|^[^ ]+ on ([^ ]+) type fuse.+|\1|;
/^${SOURCE//\//\\\/}.+/ {
s|^${SOURCE//\//\\\/}| --exclude |;
p;
}
}" ) )
rsync $OPTIONS "${FUSEEXCLUDE[#]}" "$SOURCE" "$TARGET"
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 had a typo in my fstab and it boots to a commandline but is readonly, I know what the error is but i can't change it because it's mounted as readonly. I want to mount the filesystem and make the changes. I know I can boot a live distro and edit it that way, but i was wondering if there was an easier way to do it.
It's debian lenny by the way.
Yes, if you end up in single-user mode with a readonly root, try:
mount / -o remount,rw
Maybe a -n is necessary, maybe not. That should remount the root fs read/write (assuming there's nothing wrong with it).
I know that question is outdated, but saw it, because nowadays got in the same trouble.
I broke my fstab manually (make a typo in parameter).
That was very easy to correct fstab from readonly mode. We must mount / in read-write mode.
If /etc/fstab is correct, you can simply type:
mount -n -o remount /
But if /etc/fstab is wrong (as it was in my case), you must give the device name and possibly the type, too: e.g.
mount -n -o remount -t extX /dev/hdaX /
Where extX is your filesystem type and /dev/hdaX -- is partition you use for your root mount point.
To see all your available partitions just type ls /dev/[sh]d*.
#mount -n -o remount,rw /
if /dev/sda1 is the real device, then do:
#mount -n -o remount,rw /dev/sda1 /
#troyane saved my hassle by providing
mount -n -o remount -t extX /dev/hdaX /
I was on Orangepi3 EMMC when I had a typo in UUID of root having ext4 filesystem.
The command remounted in read-write mode and I fixed my fstab
mount -n -o remount -t ext4 /dev/mmcblk2p1 /
My kernel command line looks like this:
$ cat /proc/cmdline
root=/dev/sda4 ro
$
Tell grub that it should omit passing "ro" to the kernel when booting (pressing esc, e on the entry you want edit will allow you to edit the arguments given to the kernel), and it will mount your root file system not read only anymore. Then you can change your /etc/fstab and restart.
In my case, in grub2 after pressing "e" I have changed "ro" to "rw init=/bin/bash" then the root filesystem is mounted read and write so I could change the content of /etc/fstab file.
If you have something wrong with your /etc/fstab file. Please follow the following steps.
boot your ubuntu system or restart your computer
since you can not start your system, you will encounter some errors like
“a start job is running for dev-disk-by....
(you may need pressing F2 key to come the linux command terminal to see this)
use command vi /etc/fstab and edit your fstab file
use # to commend out some problems and add something you want put in the fstab file.
finish editing. hit shift+z and save the modification
use command reboot to restart your system
it works again
Please comment here, if you have questions