When I mount a directory in Minikube and list out the directory, I get the errors below:
ls: cannot access '/mnt/nilla/assets': Bad file descriptor
ls: cannot access '/mnt/nilla/lib': Bad file descriptor
ls: cannot access '/mnt/nilla/priv': Bad file descriptor
ls: cannot access '/mnt/nilla/config': Bad file descriptor
ls: cannot access '/mnt/nilla/README.md': Bad file descriptor
ls: cannot access '/mnt/nilla/mix.exs': Bad file descriptor
ls: cannot access '/mnt/nilla/test': Bad file descriptor
ls: cannot access '/mnt/nilla/testmount': Bad file descriptor
total 0
-????????? ? ? ? ? ? README.md
d????????? ? ? ? ? ? assets
d????????? ? ? ? ? ? config
d????????? ? ? ? ? ? lib
-????????? ? ? ? ? ? mix.exs
d????????? ? ? ? ? ? priv
d????????? ? ? ? ? ? test
-????????? ? ? ? ? ? testmount
This is problem because when I mount this directory in my pod, the lsyncd service is copying it to a distribution folder. lsyncd does not know what to do with files that don't have proper descriptors.
I mount the the volume after starting Minikube, like:
nohup minikube mount ${HOME}/Development/nilla/:/mnt/nilla &> /dev/null &
How can I mount a directory and transfer the normal file descriptors that appear when I list the directory on my local computer? These are what they look like:
$ < ls -l nilla/
total 28
drwxr-xr-x 6 joes joes 4096 Apr 10 22:23 assets
drwxr-xr-x 2 joes joes 4096 Apr 10 22:23 config
drwxr-xr-x 4 joes joes 4096 Apr 10 22:23 lib
-rw-r--r-- 1 joes joes 1905 Apr 10 22:23 mix.exs
drwxr-xr-x 4 joes joes 4096 Apr 10 22:23 priv
-rw-r--r-- 1 joes joes 735 Apr 10 22:23 README.md
drwxr-xr-x 4 joes joes 4096 Apr 10 22:23 test
-rw-rw-r-- 1 joes joes 0 May 15 23:08 testmount
Additional notes: I'm using System 76's Pop OS, which is a fork of Ubuntu 20, and my Minikube VM is running Ubuntu 20 on Virtual Box.
Thanks.
#MikołajGłodziak in the comments pointed me in the right direction. The problem was the default driver for Minikube. I changed my minikube start command to specify one of the recommended drivers. As an example:
minikube start --driver=docker --mount-string ${HOME}/project/:/mnt/project
NOTE: You may get errors for trying to start up the same Minikube VM with a different driver. If that's the case, minikube delete will delete your current VM and make a new one the next time you run minikube start.
This seems to be an issue with minikube, which is currently being worked on.
See https://github.com/kubernetes/minikube/issues/12301
Current workaround is to use another driver.
easy way to do this
minikube start --driver=docker --mount-start="${HOME}/project/host" --mount
Related
I hope someone can help me with my problem.
Background: I want to mount very big ISOs to my raspberry via sftp.
If I try to mount the iso from a local folder, for example Downloads\2005-2010.iso it works perfect. But if I try to mount the ISO from a mounted sshfs folder, it fails. I also tryed to change the permission to 777 (only for testing) to the mounted ftp folder, but no success.
I using "sshfs" to mount my ftp webhosting folder. (Works perfect)
The Output is different to the following statements:
Statement
sudo mount /home/pi/isomount/2005-2010.iso /home/pi/medien/2005-2010/
1.1 Output
mount: /home/pi/medien/2005-2010: cannot mount /home/pi/isomount/2005-2010.iso read-only.
Statement
sudo mount -o loop /home/pi/isomount/2005-2010.iso /home/pi/medien/2005-2010/
2.1 Output
mount: /home/pi/medien/2005-2010/: failed to setup loop device for /home/pi/isomount/2005-2010.iso.
Any idears what I can do to mount this .iso?
For me, this worked :
sudo bash
# Now in root
mkdir /tmp/iso
mount /home/pi/isomount/2005-2010.iso /tmp/iso
More details
~# cd /home/ubuntu/dev
/home/ubuntu/dev# df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
User#remotehost:dev 487213052 380126780 107086272 79% /home/ubuntu/dev <-- sshfs mounted
/home/ubuntu/dev# ls -l ubuntu-20.04.3-desktop-amd64.iso
-rwx------ 1 197609 197121 3071934464 Dec 28 10:44 ubuntu-20.04.3-desktop-amd64.iso
/home/ubuntu/dev# mount ubuntu-20.04.3-desktop-amd64.iso /tmp/iso
mount: /tmp/iso: WARNING: device write-protected, mounted read-only.
/home/ubuntu/dev# ls -ltr /tmp/iso
total 101
lr-xr-xr-x 1 root root 1 Aug 19 11:59 ubuntu -> .
dr-xr-xr-x 1 root root 2048 Aug 19 11:59 preseed
dr-xr-xr-x 1 root root 2048 Aug 19 11:59 pool
dr-xr-xr-x 1 root root 2048 Aug 19 11:59 dists
dr-xr-xr-x 1 root root 2048 Aug 19 12:01 install
dr-xr-xr-x 1 root root 2048 Aug 19 12:01 casper
dr-xr-xr-x 1 root root 2048 Aug 19 12:01 boot
dr-xr-xr-x 1 root root 2048 Aug 19 12:01 EFI
dr-xr-xr-x 1 root root 34816 Aug 19 12:01 isolinux
-r--r--r-- 1 root root 53487 Aug 19 12:03 md5sum.txt
My sshfs mount options in /etc/mtab :
User#remotehost:dev /home/ubuntu/dev fuse.sshfs rw,nosuid,nodev,relatime,user_id=1001,group_id=1001,allow_other 0 0
I have added the following to the file /etc/sudoers using the visudo command:
nick ALL=(ALL:ALL) ALL
But when I log in as nick and attempt something like mkdir .ssh I get:
mkdir: cannot create directory ‘.ssh’: Permission denied
Likewise, I cannot save files I have edited.
Running ls -la from the home directory gives me:
drwxr-xr-x 5 nick nick 4096 Apr 7 19:07 .
drwxr-xr-x 3 root root 4096 Apr 7 17:32 ..
-rw-r--r-- 1 nick nick 220 Aug 31 2015 .bash_logout
-rw-r--r-- 1 nick nick 3771 Aug 31 2015 .bashrc
drwx------ 2 nick nick 4096 Apr 7 18:29 .cache
drwxr-xr-x 2 root root 4096 Apr 7 19:07 .nano
-rw-r--r-- 1 nick nick 675 Aug 31 2015 .profile
Which if I'm not mistaken is showing that I have no write access to anything. (Correct me if I'm wrong. I'm only passingly familiar with UNIX permissions.)
Why can't this user do anything despite being given full permissions in sudoers?
UPDATE:
This problem fixed itself. I do not know what the problem was but it was no longer a problem when I logged on a couple days later.
For the record, I was attempting to configure a fresh DigitalOcean server running Ubuntu 15.10 x64. My local computer is a MacBook running El Capitan.
My guess is that the remote server restarted or somehow otherwise incorporated the change automatically in the interim. I had already tried running sudo reboot producing no results, so I'm still not sure how this could be.
I was also experiencing some local WiFi connection dropping at the time but as my SSH connection seemed to be operational I'm not sure if this could be related.
I'm also not an expert to Linux, but to me it seems like you have to use sudo mkdir .ssh instead of mkdir .ssh. You allowed your user to behave like root(who has rights to write to directory), but for doing that you have to use sudo command.
Here is the simple explanation of how it works(with pictures): https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html
Here is the serious documentation: https://help.ubuntu.com/community/Sudoers
I am new to linux. when i list the files under folder 1, i see below result
-rwxrwxrwx 1 root root 920 Jun 3 10:36 file1.xsd
-rwxrwxrwx 1 root root 920 Jun 3 10:36 file2.xsd
drwxrwxrwx 2 ubuntu ubuntu 4096 Jun 12 11:10 temp
-rwxrwxrwx 1 ubuntu ubuntu 1853 Jun 19 11:07 file3.xsd
for some files(file1 and file2) root root is written after permisionsbut for file3 ubuntu ubuntu is displayed.
what is difference b/w ubuntu ubuntu and root root ?
How can i change ubuntu ubuntu for file 3 to root root ?
The first "root" stands for user name and second "root" stands for the group name. By design, Ubuntu uses "sudo" command to run other commands "as root", and the actual root user is not used.
So what that means, every time you use the command sudo to run a command, it is actually being done as root. That's most likely the reason for the two of your files being owned by root (and the group root).
You can change the ownership of the file with command chown:
chown root:root file3.xsd
I'm trying to provide my docker container a volume of encrypted file system for internal use.
The idea is that the container will write to the volume as usual, but in fact the host will be encrypting the data before writing it to the filesystem.
I'm trying to use EncFS - it works well on the host, e.g:
encfs /encrypted /visible
I can write files to /visible, and those get encrypted.
However, when trying to run a container with /visible as the volume, e.g.:
docker run -i -t --privileged -v /visible:/myvolume imagename bash
I do get a volume in the container, but it's on the original /encrypted folder, not going through the EncFS. If I unmount the EncFS from /visible, I can see the files written by the container. Needless to say /encrypted is empty.
Is there a way to have docker mount the volume through EncFS, and not write directly to the folder?
In contrast, docker works fine when I use an NFS mount as a volume. It writes to the network device, and not to the local folder on which I mounted the device.
Thanks
I am unable to duplicate your problem locally. If I try to expose an encfs filesystem as a Docker volume, I get an error trying to start the container:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
So it's possible you have something different going on. In any case, this is what solved my problem:
By default, FUSE only permits the user who mounted a filesystem to have access to that filesystem. When you are running a Docker container, that container is initially running as root.
You can use the allow_root or allow_other mount options when you mount the FUSE filesystem. For example:
$ encfs -o allow_root /encrypted /other
Here, allow_root will permit the root user to have acces to the mountpoint, while allow_other will permit anyone to have access to the mountpoint (provided that the Unix permissions on the directory allow them access).
If I mounted by encfs filesytem using allow_root, I can then expose that filesystem as a Docker volume and the contents of that filesystem are correctly visible from inside the container.
This is definitely because you started the docker daemon before the host mounted the mountpoint. In this case the inode for the directory name is still pointing at the hosts local disk:
ls -i /mounts/
1048579 s3-data-mnt
then if you mount using a fuse daemon like s3fs:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
My guess is that docker does some bootstrap caching of the directory names to inodes (someone who has more knowledge of this than can fill in this blank).
Your comment is correct. If you simply restart docker after the mounting has finished your volume will be correctly shared from host to your containers. (Or you can simply delay starting docker until after all your mounts have finished mounting)
What is interesting (but makes complete since to me now) is that upon exiting the container and un-mounting the mountpoint on the host all of my writes from within the container to the shared volume magically appeared (they were being stored at the inode on the host machines local disk):
[root#host s3-data-mnt]# echo foo > bar
[root#host s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[root#host s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash
root#5592454f9f4d:/mounts/s3-data# ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
root#5592454f9f4d:/s3-data# echo baz > beef
root#5592454f9f4d:/s3-data# ls -als
total 9
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef
root#5592454f9f4d:/s3-data# exit
exit
[root#host s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[root#host /]# umount -l s3-data-mnt
[root#host /]# ls -als
[root#ip-10-0-3-233 /]# ls -als /s3-stn-jira-data-mnt/
total 8
4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
You might be able to work around this by wrapping the mount call in nsenter to mount it in the same Linux mount namespace as the docker daemon, eg.
nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ...
The question is whether this approach will survive a daemon restart itself. ;-)
I have created a root filesystem with buildroot that is using squashfs. It works fine, and now I would like to create an overlayfs, which would hold /home and /etc directories.
For this purpose, I wanted to create a simple jffs2 filesystem with couple of files:
jlumme#simppa:~/projects/jffs2_home$ ls -la
total 20
drwxrwxr-x 4 jlumme jlumme 4096 Apr 21 16:21 .
drwxrwxr-x 6 jlumme jlumme 4096 Apr 21 16:21 ..
drwxrwxr-x 2 jlumme jlumme 4096 Apr 21 13:45 default
drwxrwxr-x 2 jlumme jlumme 4096 Apr 21 13:45 ftp
-rw-rw-r-- 1 jlumme jlumme 24 Apr 21 15:34 test.txt
The flash chip I use is SST25VF064C, so I believe it's erase block size is 64 KB, and thus I create a filesystem image from that folder:
mkfs.jffs2 -r jffs2_home/ -e 64 -o home.jffs2
$ ls -la
-rw-r--r-- 1 jlumme jlumme 496 Apr 21 15:42 home.jffs2
(Suprisingly, if I set -e 32, or even -e 4, the resulting binary image doesn't change at all???).
Nevertheless, moving on, I have aligned my mtdblock that contains home, to 64KB, and my flash layout looks like this:
uboot/<0x00000000 0x40000>
kernel/<0x00040000 0x3D9000>
dtb/<0x00419000 0x10000>
rootfs/<0x00429000 0x1F7000>
home/<0x00620000 0x1E0000>
On my board, I can mount the mtdblock4 fine, and I can read the file contents properly. However, if I modify the file, and try saving it, vi complains:
[ 77.030000] jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Now, if I unmount the filesystem, and remount it, I start getting complaints immediately:
# mount -t jffs2 /dev/mtdblock4 /home/
[ 99.740000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d4070: 0xff0a instead
[ 99.760000] jffs2: Empty flash at 0x001d4074 ends at 0x001d412c
[ 99.770000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d412c: 0xffff instead
[ 99.790000] jffs2: Empty flash at 0x001d4130 ends at 0x001d4194
[ 99.790000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d4194: 0xff0a instead
I suppose now my filesystem is already corrupted... and I don't really understand the reason for it..
Any ideas where am I going wrong with this ? Thanks for all suggestions..
This is what I did to solve the issue.
Updated newer MTD drivers from http://www.linux-mtd.infradead.org/
- There was new code for SST25V064C chip
Made sure the area reserved for JFFS2 was initialized to 0xFF
(possibly optional) Specified more accurately the creation of jffs2 file system:
mkfs.jffs2 -e 64 -l -p -s 4096 -r jffs2_home/ -o home.jffs2
With these changes the file system now reads and writes as expected.