How can mount a partition in an already existent folder of my linux tree? What happens with the already created file and can I move these to the new disk in the process?
I am using a Ubuntu 16.04 with an SSD and HD disk, I would like to mount the ~/Documents or $HOME in the HD moving the files already created and free the SSD to the main files of the operation system (in this moment all the files are in the SSD and the HD is only formatted as Ext4).
The moment you mount the new parition on top off ~/Documents you cant access the Files anymore, but there are some Options:
Mount the HD somewhere else first and move the files. (code is just an example, it is not supposed to be executable as is)
mount /dev/disks/by-lable/foo /media/temporary
mv /home/hildogjr/Documents/* /media/temporary
umount /media/temporary
mount /dev/disks/by-lable/foo /home/hildogjr/Documents
Use a bindmount, to still be able to access the files after mounting:
mount --bind /home/hildogjr/Documents /media/Documents_on_ssd
mount /dev/disks/by-lable/foo /home/hildogjr/Documents
mv /media/Douments_on_ssd/* /home/hildogjr/Documents
umount /media/Documents_on_ssd
Use a unionfs, and move the files over Time. man unionfs:
It first tries to access the file on the top branch and if the file
does not exist there, it continues on lower level branches. If the
user tries to modify a file on a lower level read-only branch the file
is copied to to a higher level read-write branch if the copy-on-write
(cow) mode was enabled.
Related
I am writing some tools that operate on files stored inside a disk image file under a users control. FUSE tools like fuse2fs are used to access file systems inside of partitions of those image files.
However, mounting those filesystems, and even accessing parts of it still require superuser privileges (and a lot of kernel work), as FUSE will still register the filesystem in kernel space, provide an /etc/mtab entry and VFS mount of course.
FUSE allows some configuration to allow a non-privileged user to mount such FS, but fuse2fs still enforces user rights.
So I wonder if something can be done to stop for example fuse2fs exporting the fs to kernel space at all, and just access files in userspace. Like a wrapper, used like this:
fusewrapper --fuse-cmd="fuse2fs foo.img /bar" ls /bar/ # lists "/" of foo.img's ext4 FS
fusewrapper --user=root --group=root --fuse-cmd="fuse2fs foo.img /bar" cat /bar/baz # prints "/baz" contents from foo.img's ext4 fs as root.
where /bar is a virtual mount path only valid inside of the fusewrapper universe and ls / cat internal fusewrapper command to list or cat the named path.
This tool would only use the kernel for access to foo.img and stdin / out, and can still impersonate any user (eg. root).
How could such a tool work? What is needed to get rid of FUSEs non-userspace parts (eg. kernel interface) ?
I have a vm(on vmware fully running). But i want to do some modification and put all file system to single partition /.
In my current VM i have /, /var, /tmp, /boot partition.
Action performed:
Attached new hard disk, formatted and created two partition (one for / and another for swap)
made / as active partition for root.
copied all the files from original hard disk to new harddisk.
made changes in /etc/fstab and run grub-install.
detached new harddisk and created new VM using this harddisk.
Now when I am starting VM, I got
"Error 15: File not found"
Just got answer while hitting and trying . This error is due to /etc/grub/grub.conf file. When we have /boot partition we don't need to give whole path for kernel for example :
Kernel /< kernel version>
but when we have single root partition only, means no /boot partition we need to provide complete path, example:
Kernel /boot/< kernel version>
And same for initrd line.
It worked for me.
I would like to know is it possible through symbolic (soft) link to move files from one location (A) to another (B) when files are getting created in the A location.
So you have some program creating files in some directory (e.g. in /fixed/location/), and you want the data to be elsewhere (e.g /data/dir/somefile.txt...)
If you know in advance the name of the created files, you could make them symbolic links before starting the program:
ln -s /data/dir/somefile.txt /fixed/location/file.txt
and if you create that symbolic link before running the program, it will write the data into /data/dir/somefile.txt even if that file does not exist (but the directory /data/dir should exist when you type that ln -s)
Another (Linux specific) possibility is to make a bind mount. If e.g. you want the data inside /usr/src/ to reside in /home/Src/ you could first mkdir /home/Src then e.g. add the following line in your /etc/fstab file:
/usr/src /home/Src none bind 0 0
I'm actually doing that (on /usr/src and /usr/local) for every Linux system where /home/ is a different filesystem, because I want them to be in the same backed up file system as /home/
I want to create a new VFAT image and add a few files to it.
# Create file of 1MB size:
dd if=/dev/zero of=my-image.fat count=1 bs=1M
# Format file as VFAT:
mkfs.vfat ./my-image.fat
Now I want to add the files ./abc, ./def and ./ghi to the image.
How do I do that without mount -o loop or fusermount?
I only want to write to a new, empty, pristine VFAT image.
I don't need deleting appending or any "complicated" operations.
I tried 7z -a because 7zip can read VFAT images, but it does not know how to write to it.
I want to do the exact same thing as part of an image build for an embedded system. It's really annoying that the entire build, which takes ~3hrs, could be completely unattended except for the final steps which required a password in order to mount a VFAT image. Fortunately, I found a set of tools which solve the problem.
You want mcopy provided by GNU mtools.
Mtools is a collection of utilities to access MS-DOS disks from GNU and Unix without mounting them.
It also supports disk images such as VFAT image files.
As an example, the following command will copy the file hello.txt from your current directory into the subdirectory subdir of the VFAT file system in ~/images/fat_file.img:
mcopy -i ~/images/fat_file.img hello.txt ::subdir/hello.txt
There are more useful inclusions in mtools, such as mdir and mtype which are great for inspecting your image file without having to mount it.
mdir -i ~/images/fat_file.img ::
mdir -i ~/images/fat_file.img ::subdir
mtype -i ~/imags/fat_file.img ::subdir/hello.txt
What you want is basically impossible. You can't just "stuff" some file data onto the end of a disk image and have those files magically "appear" within the image. Feel free to stuff in the data, but there's more to a filesystem than just the data. You have to EXACTLY replicate the metadata operations that the file system handles for you, e.g. updating the FAT tables.
In other words, you'd have to build the ENTIRE FAT filesystem handling code in your own code. Which is utterly ludicrous. Just mount the image, use normal file operations on that mounted file system, then dismount it again. Boom, done.
I am trying to do a soft link from one directory to another, the directory I am trying to access I have read and execute. However, its parent directory I do NOT have execute permissions.
Is there a way to do a soft link, to my desired directory without giving me execute permission to the parent directory?
Below is the code I used:
ln -s /home/dir1/dir2/desired_directory symbolic_link_name
the link just comes up as red with grey background.
Thank you.
Although this is not possible with symlinks, you could do it with mount --bind. Note that if the whole point is to circumvent security, then this is probably a very bad idea.
Your command would be
mount --bind /home/dir1/dir2/desired_directory mount_dir
There are a few issues to be aware of:
The target directory mount_dir must exist before (same as any mount point)
Root access is required to execute the mount commmand
The created "link" will not persist after a reboot unless a corresponding line is added to /etc/fstab
If the origin directory contains mounted file systems, these will not be transferred to the target. The mount points will appear as empty directories.
Using mount --bind may be considered bad practice because most programs are not aware that the "link" is not a standard directory. For instance it allows the creation of loops in the directory tree which make any tree parsing application (think "ls -R") enter a possibly infinite loop.
It may be hazardous when combined with recursive delete operations. See for instance Yet another warning about mount --bind and rm -rf.
Symbolic links are not a way to circumvent permissions set on their targets. No, there is no way to do what you want. If it was possible it would be a serious security issue.