I have to mount five of my main directories viz. (/home, /usr, /tmp, /root and /var) for a specific project. I did some googling and found out a set of commands which can be executed to mount a particular directory. The commands were as follows:
#dd if=/dev/zero of=/filesystems/tmp_fs seek=512 count=80000000 bs=1M
#mkfs.ext3 /filesystems/tmp_fs
After mounting, the entry was registered in fstab as below,
/filesystems/tmp_fs /tmp ext3 noexec,nosuid,loop 1 1
And at the last step, the directory was mounted.
I followed the same procedure for mounting all the directories specified above. In the end, I could only mount "/root" and "/tmp" directories without any errors. Rest all the three directories gave some or the other error. After mounting '/home' directory, I am getting the following error "No directory. logging in with HOME=/" and similarly after mounting '/var'
directory I got the following error "/var/lib/apt//lists No such file
or directories". Mounting of '/usr' directory caused the OS to crash as
a result of which we could not even login as root user and also some
basic commands like 'vi' and 'sudo su', to name a few were not found in
the system. ecause of these issues, the only option left was to format
the OS since we could not even revert this step because of the missing
commands.
Any help or suggestion here in the right direction would be of great help here.
Thanks for the consideration.
Related
sync: failed to set times on "/." (in XXXXXXXXXXX): Operation not permitted (1)
./
sent 483,746 bytes received 2,706 bytes 324,301.33 bytes/sec
total size is 161,339,379,726 speedup is 331,665.57
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
ERROR: The synchronisation failed.
Done ...
I got this weird "/." I don't get what is this path or even what it refers to.
Since it's an error 23, I can confirm that other files are well transferred. All have different rights and groups that are indeed compatible.
Also I do not want to use --omit-dir-times.
So how do I fix this ? Where is or what is "/."?
how do I fix this ?
Possible run the command as root or as an owner of current directory.
Where is or what is "/."?
This path seems to be absolute, it's the file system root directory - /.
From wikipedia path (computing):
Two dots ("..") point upwards in the hierarchy, to indicate the parent directory; one dot (".") represents the current directory itself.
The destination dir/folder does not allow modification of the specific folder.
eg.
rsync: [generator] failed to set times on "/mnt/tmp/.": Operation not permitted
I was mounting a ISO or UDF file image through the loop filesystem to /mnt/tmp. The required folder permissions were not permissive enough, and should be changed prior to mounting the filesystem to /mnt/tmp.
Although just a warning, still interferes with interpreting the command return value upon exit of the command.
Change the dir/folder permissions prior to mounting or working with the folder, or add yourself to the group with appropriate group permissions.
chmod -R a+rwX /mnt/tmp
I have experienced the same problem: In my case the cause was some bad extended filesystem attribute setting.
Specifically, I had set "chattr +i /path/to/somedir", by mistake, and therefore made somedir (and content) unwritable. To fix, use "chattr -i /path/to/somedir
It may not be so obvious that attributes are the problem. The permissions may be all good (say rwx), but attributes overrule those regular unix permissions.
I found that I had not reconfigured my repository to use ssh. The error listed is what I got. I then changed my .git/config file to use ssh: and it cleared up.
I wrote a little program, where i mounted an encrypted volume after the user inserts the password with veracrypt an showed the content to the user in a specific way inside my programm. Everything works fine, but i want to prevent that the volume is shown in Nautilus.
The following command mounts the volume:
"veracrypt -m ro /path/to/file/file -p" + pw
Veracrypt help command shows:
--fs-options=OPTIONS
Filesystem mount options. The OPTIONS argument is passed to mount(8)
command with option -o when a filesystem on a VeraCrypt volume is mounted.
This option is not available on some platforms.
But i'm not able to find a mount option for linux-mount command, which will do the job. Is there any? What can i do?
A simple workaround may be to mount the volume to a directory that begins with a .. These directories should not be visible in most file managers without specifying they should show hidden files/folders.
Of course, obscuring the folder isn't perfect and is no substitute for setting proper access control specifies via chmod.
I am using a script on RHEL server where I'm copying a backup of the /etc/syslog.conf file before making configurable changes in it. I used the below command in the script:
cp -pr /etc/syslog.conf /etc/syslog.conf.bkp.`date +"%d%m%Y"`
The script ran absolutely fine on one RHEL server, but on the other it shows the below error:
cp: cannot stat `/etc/syslog.conf': No such file or directory
I also checked the /etc/syslog/conf file exists in the server just fine.
Why is the difference of behaviour. How to resolve it ?
cp: cannot stat is mainly because cp command can't see the file. It can be for two reasons.
File is not present
You don't have permission to view the file.
If you check these two things you should be able to find the answer
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.
I have a folder /cygwin/d/myfolder/
And everytime I save files there, from cygwin if i do an ls -la I see that the files are given permission 000. That actually causes me quite a bit of problem as I rsync this folder to my server and none of the files are accessible. How can I get the files to automatically get a reasonable permission?
Have a read through the answers at this link:
http://cygwin.1069669.n5.nabble.com/vim-and-file-permissions-on-Windows-7-td61390.html
The solution there worked for me also:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Then close all Cygwin processes, open a new terminal and ls -l on your files again.
Explanation:
By default, Cygwin uses the filesystem's access control lists (ACLs) to implement real POSIX permissions. Some Windows-native program or process may create or modify the ACLs such that Cygwin computes the POSIX permissions as 000. With the noacl mount option, Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute.
Check to make sure that your umask is set correctly with the umask command. If your umask is say 0777 that subtracts from the permissions of new files and will end up with 000 permissions. There's probably several other possibilities to consider beyond that.
If your id is not set up correctly in /etc/passwd and /etc/group that can also cause ls to show unexpected results. Check the permissions of the folder. Also check the Windows permissions with the getfacl command. Maybe also check the mount command.
In above answer, solution was proposed:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
And in that answer there was this comment:
When I try this, all my files are -rw-r--r-- no matter what chmod() I do. I can't mark the files as executable; it just reverts to 0644. (umask==0022)
I had this same problem, but it manifested in inability to execute DOS batch files (*.bat) when running Cygwin ksh or mksh. I stumbled across this website: http://pipeline.lbl.gov/code/3rd_party/licenses.win/cygwin-doc-1.4/html/faq/ which contains this helpful advice:
Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.
So then cross-referencing with this page - https://cygwin.com/cygwin-ug-net/using.html#mount-table - with its advice:
cygexec - Treat all files below mount point as cygwin executables.
I added cygexec to fourth field of my fstab. This did it. My .bat is now executable inside ksh/mksh, which is necessary since I'm running a Jenkins job that calls a Korn shell stack 3 files deep, that I have no modifiable control over. I just needed the .bat to run!
Update: the solution above wasn't quite what I needed, on further testing. It resulted in some executables such as javac and cl to behave oddly (the utilities would print their usage and exit). I think what I needed instead of 'cygexec' was just 'exec'. As the same page notes:
exec - Treat all files below mount point as executable.
On my Win7 PC files were usually
----------+ 1 David None 69120 Jun 17 13:17 mydoc.txt
I tried all of above no luck
Turned out I still had some old historical mount entries in my .zshrc
I deleted these and Bob's your Uncle problem gone away!