I'm running Max OSX 10.9.3 and I'm trying to setup an SSHFS file-share between my MacBook Pro and a remote file system. However, when I try to do it, it doesn't work.
Strangely enough, it makes the target directory disappear. Has anyone else seen this happen? Is it a bug?
First see that I can ssh normally into the target machine:
% ssh remoteuser#XXX.XXX.XXX.XXX # <--- SSH to remote system works! See below.
remoteuser#XXX.XXX.XXX.XXX % ls -altr remoteDir
total 8
drwxr-xr-x 26 remoteuser remoteuser 4096 Jun 22 01:00 ..
drwxrwxrwx 2 remoteuser remoteuser 4096 Jun 22 01:08 .
remoteuser#XXX.XXX.XXX.XXX % exit
% # <--- Logged out of remote system
Next, I create a directory locally and verify it was created:
% pwd
/mnt
% ls
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 2 root admin 68 Jun 23 08:11 ./
% sudo mkdir share1
% ls
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 4 root admin 136 Jun 23 08:50 ./
drwxr-xr-x 2 root admin 68 Jun 23 08:50 share/
Now I try to setup the SSHFS share:
% sudo sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
remoteuser#XXX.XXX.XXX.XXX's password:
%
Ok. It seems to have worked. No errors. So let's see the share we created, shall we?
% ls
ls: share1: No such file or directory
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 3 root admin 102 Jun 23 08:12 ./
What? Not only is the File Sharing not working, but the share1 directory seems to have vanished! (Although the file system seems to know it is missing, which is weird).
Where did /mnt/share1 go and how do I setup this SSHFS?
SSHFS doesn't come with OS X AFAIK, so you should mention how you installed it. But I'm guessing sshfs is designed to be used with fstab or mount rather than be called directly. Try something like:
mount -t sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
Related
I wrote a docker-compose.yml like this:
version: "3"
services:
notebook:
image: jupyter/datascience-notebook
ports:
- "8888:8888"
volumes:
- jupyterlabPermanent:/hahaha
environment:
JUPYTER_ENABLE_LAB: "yes"
TZ: "Asia/Tokyo"
command:
start-notebook.sh --NotebookApp.token=''
volumes:
jupyterlabPermanent:
Let me make it clear that what characters are appearing on the stage.
\hahaha: container side directory which is located at the root directory
jupyterlabPermanent: volume which is mounted by hahaha the container side directory.
dockerjulia_jupyterlabPermanent\_data: host side directory secured for volume jupyterlabPermanent which syncronize the data located in \hahaha.Full path to dockerjulia_jupyterlabPermanent\_data is \\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\dockerjulia_jupyterlabPermanent\_data.
When I use touch command on bash at \hahaha directory, I get permission denied
# bash command line at \hahaha
(base) jovyan#4bcdaa228d9e:/hahaha$ touch test.txt
touch: cannot touch 'test.txt': Permission denied
Because of this, every tasks done in the container cannot be stored in the \hahaha and jupyterlabPermanent volume, and this means data saving is not working in this environment.
How can I solve this?
I searched a bit for this, and found I need to change the configuration of permission, but I don't understand it.
I am using Docker Desktop for Windows with WSL 2 on Windows 10 Home.
You need root access on the volume to change the permissions. So let's run a plain Ubuntu container and mount the volume
docker run -it --rm -v jupyterlabPermanent:/hahaha ubuntu
now we can change the group ownership to GID 100 which is the group the jovyan user is a member of and also change the permissions to 775 so group members can write to it
chown :100 /hahaha
chmod 775 /hahaha
Now you can exit the Ubuntu container and run the jupyter container and you should be able to write to the volume.
Thank you for answering my question. The main problem was that I didn't know the existence of the concept of "owner" and "permission" of Linux system. But, an hour of research and learning let me figure out what the problem here is.
My solution 1
My first solution is to try the following command line on Host console:
docker exec -it -u 0 CONATAINER_NAME /bin/bash
Adding -u option and designating 0, the User ID of root, lets you dive into the container as you are root.
As I checked using ll command at the top directory of the container, the permissions of the files and folders at the top directory of the container appears to be dominated by root, and the hahaha is the one of them.(It means docker-compose.yml created hahaha directory for volume at the top directory)
(base) jovyan#4bcdaa228d9e:/$ ll
total 64
drwxr-xr-x 1 root root 4096 Jan 26 00:19 ./
drwxr-xr-x 1 root root 4096 Jan 26 00:19 ../
lrwxrwxrwx 1 root root 7 Jan 6 01:47 bin -> usr/bin/
drwxr-xr-x 2 root root 4096 Apr 15 2020 boot/
drwxr-xr-x 5 root root 340 Jan 26 00:19 dev/
-rwxr-xr-x 1 root root 0 Jan 26 00:19 .dockerenv*
drwxr-xr-x 1 root root 4096 Jan 26 00:19 etc/
drwxr-xr-x 2 root root 4096 Jan 27 22:18 hahaha/
drwxr-xr-x 1 root root 4096 Jan 24 20:30 home/
lrwxrwxrwx 1 root root 7 Jan 6 01:47 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 Jan 6 01:47 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 Jan 6 01:47 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root 10 Jan 6 01:47 libx32 -> usr/libx32/
drwxr-xr-x 2 root root 4096 Jan 6 01:47 media/
drwxr-xr-x 2 root root 4096 Jan 6 01:47 mnt/
drwxr-xr-x 1 root root 4096 Jan 25 02:49 opt/
dr-xr-xr-x 217 root root 0 Jan 26 00:19 proc/
drwx------ 2 root root 4096 Jan 6 01:50 root/
drwxr-xr-x 5 root root 4096 Jan 6 01:50 run/
lrwxrwxrwx 1 root root 8 Jan 6 01:47 sbin -> usr/sbin/
drwxr-xr-x 2 root root 4096 Jan 6 01:47 srv/
dr-xr-xr-x 11 root root 0 Jan 26 00:19 sys/
drwxrwxrwt 2 root root 4096 Jan 6 01:50 tmp/
drwxr-xr-x 1 root root 4096 Jan 6 01:47 usr/
drwxr-xr-x 1 root root 4096 Jan 6 01:50 var/
Therefore, there was no permission for jovyan to touch something at hahaha at the top directory dominated only by root, and this is made it by diving into the container as root.
My solution 2
The second solution is to rewrite the docker-compose.yml as follows:
version: "3"
services:
notebook:
image: jupyter/datascience-notebook
ports:
- "8888:8888"
volumes:
#
- jupyterlabPermanent:/home/jovyan/hahaha # before -> jupyterlabPermanent:/hahaha
environment:
JUPYTER_ENABLE_LAB: "yes"
TZ: "Asia/Tokyo"
command:
start-notebook.sh --NotebookApp.token=''
volumes:
jupyterlabPermanent:
This change lets docker-compose create container as volume mounting directory is set at /home/jovyan/hahaha.
The files and folders under /home/jovyan is owned and by jovyan(not by root) so jovyan can touch some files at /home/jovyan/hahaha freely. (No need to dive into the container as root)
I am trying run docker inside WSL (am running Ubuntu in WSL). Also am new to docker. The doc says:
To get the best out of the file system performance when bind-mounting files:
Store source code and other data that is bind-mounted into Linux containers (i.e., with docker run -v <host-path>:<container-path>) in the Linux filesystem, rather than the Windows filesystem.
Linux containers only receive file change events (“inotify events”) if the original files are stored in the Linux filesystem.
Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users (where /mnt/c is mounted from Windows).
Instead, from a Linux shell use a command like docker run -v ~/my-project:/sources <my-image> where ~ is expanded by the Linux shell to $HOME.
I also came across following:
Run sudo docker run -v "$HOME:/host" --name "[name_work]" -it docker.repo/[name]. With, [$HOME:/host], you can access your home directory in /host dir in docker image. This allows you to access your files on the local machine inside the docker. So you can edit your source code in your local machine using your favourite editor and run them directly inside the docker. Make sure that you have done this correct. Otherwise, you may need to copy files from the local machine to docker, for each edit (a painful job).
I am not able to understand the format of parameter passed to -v option and what it does. I am thinking that it will allow to access Ubuntu directories inside docker. So $HOME:/host will map Ubuntu's home directory to /host inside.
Q1. But what is /host?
Q2. Can I do what is stated by above two quotes together? I mean what they are saying is compatible? I guess yes. What all its saying is I should not mount from windows director like /mnt/<driveletter>/.... If I am mounting linux directory like $USER/... then it will give better performance, right?
I tried out running it to understand it:
~$ docker run -v "$HOME:/host" --name "mydokr" -it docker.repo.in/dokrimg
root#f814974a1cfb:/home# ls
root#f814974a1cfb:/home# ll
total 8
drwxr-xr-x 2 root root 4096 Apr 15 11:09 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
root#f814974a1cfb:/home# pwd
/home
root#f814974a1cfb:/home# cd ..
root#f814974a1cfb:/# ll
total 64
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
-rwxr-xr-x 1 root root 0 Sep 22 07:16 .dockerenv*
lrwxrwxrwx 1 root root 7 Jul 3 01:56 bin -> usr/bin/
drwxr-xr-x 2 root root 4096 Apr 15 11:09 boot/
drwxr-xr-x 5 root root 360 Sep 22 07:16 dev/
drwxr-xr-x 1 root root 4096 Sep 22 07:16 etc/
drwxr-xr-x 2 root root 4096 Apr 15 11:09 home/
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 host/
lrwxrwxrwx 1 root root 7 Jul 3 01:56 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 Jul 3 01:56 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 Jul 3 01:56 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root 10 Jul 3 01:56 libx32 -> usr/libx32/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 media/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 mnt/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 opt/
dr-xr-xr-x 182 root root 0 Sep 22 07:16 proc/
drwx------ 1 root root 4096 Aug 24 03:54 root/
drwxr-xr-x 1 root root 4096 Aug 11 10:24 run/
lrwxrwxrwx 1 root root 8 Jul 3 01:56 sbin -> usr/sbin/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 srv/
dr-xr-xr-x 11 root root 0 Sep 22 03:32 sys/
-rw-r--r-- 1 root root 1610 Aug 24 03:56 test_logPath.log
drwxrwxrwt 1 root root 4096 Aug 24 03:57 tmp/
drwxr-xr-x 1 root root 4096 Aug 11 10:24 usr/
drwxr-xr-x 1 root root 4096 Jul 3 02:00 var/
root#f814974a1cfb:/home# cd ../host
root#f814974a1cfb:/host# ll
total 36
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
-rw-r--r-- 1 1000 1001 220 Sep 22 03:38 .bash_logout
-rw-r--r-- 1 1000 1001 3771 Sep 22 03:38 .bashrc
drwxr-xr-x 3 1000 1001 4096 Sep 22 04:56 .docker/
drwxr-xr-x 2 1000 1001 4096 Sep 22 03:38 .landscape/
-rw-r--r-- 1 1000 1001 0 Sep 22 03:38 .motd_shown
-rw-r--r-- 1 1000 1001 921 Sep 22 04:52 .profile
-rw-r--r-- 1 1000 1001 0 Sep 22 03:44 .sudo_as_admin_successful
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 .vscode-server/
-rw-r--r-- 1 1000 1001 183 Sep 22 04:52 .wget-hsts
So I am not getting whats happening here. I know docker has its own file system.
Q3. Is is that, what am finding at /home and /host is indeed container's own file system?
Q4. Also, what happened to -v $HOME:/host here?
Q5. How can I do as stated by 2nd quote:
This allows you to access your files on the local machine inside the docker. So you can edit your source code in your local machine using your favourite editor and run them directly inside the docker.
Q6. How do I connect vscode to this container? From WSL-Ubuntu, I could just run code . to launch vscode. But the same does not seem to work here:
root#f814974a1cfb:/home# code .
bash: code: command not found
This link says:
A devcontainer.json file can be used to tell VS Code how to configure the development container, including the Dockerfile to use, ports to open, and extensions to install in the container. When VS Code finds a devcontainer.json in the workspace, it automatically builds (if necessary) the image, starts the container, and connects to it.
But I guess this says starting up creating new container form vscode. But not connecting to already existing container. I am not able to find my dockercontainer.json. I downloaded this container image using docker pull.
I am using Ubunutu 20.04 and I am trying to write to a mounted Windows share. This is the command I am using to mount the share:
sudo mount.cifs //192.168.1.5/tv /mnt/tv -o username=xxxxxxxxxx,password=xxxxxxxxx,file_mode=0777,dir_mode=0777
I am able to view the contents of the Windows share in Ubuntu:
darren#homeserver:~$ ls -l /mnt/tv/
total 0
drwxrwxrwx 2 root root 0 Jun 30 15:33 '$RECYCLE.BIN'
drwxrwxrwx 2 root root 0 Jan 1 2019 MSOCache
drwxrwxrwx 2 root root 0 Apr 28 00:38 'Plex dance'
drwxrwxrwx 2 root root 0 Dec 30 2019 'System Volume Information'
drwxrwxrwx 2 root root 0 Jun 24 15:37 'TV Shows'
-rwxrwxrwx 1 root root 0 Jan 1 2019 desktop.ini
But if I try to create a test file i get this error:
[ Error writing lock file /mnt/tv/.test.swp: Permission denied ]
I have the Windows share permissions set to "Everyone":
Any thoughts?
Try this configuration:
-fstype=cifs,credentials=<fileWithCred>,vers=3.0,dir_mode=0777,file_mode=0777,noserverino ://<IP-Winshare>/Path
I am trying to give myself root access to all the file in this folder and not have to sudo everything I want to run a command.
The file I am concerned with is pro
When I enter ls -l I get :
drwxr-xr-x+ 12 Guest _guest 384 13 Jan 14:56 Guest
drwxrwxrwt 9 root wheel 288 13 Jan 14:30 Shared
drwxr-xr-x+ 148 Santi staff 4736 1 Apr 17:13 pro
then I enter chmod 775 pro/
It doesnt seem to change the permssions. What can I do to fix this or why is the folder restricting permission even though I appear to be root?
drwxr-xr-x+ ...
the final + means that the file is governed by acl
see
apropos acl : give you the mans to consult
wikipedia
Access Control Lists on Arch wiki
I have the following bash script:
#!/bin/bash
run_python(){
cd "`dirname $1`"
python "`basename $1`" $2 >test.log
}
crypto_util=/home/dev/src/crypto/util.py
run_python $crypto_util "testpassword"
Somehow cd command fails saying:
cd: /home/dev/src/crypto No such file or directory. I am quite sure the directory exists.
On a side note if I do the following this fails too:
run_python(){
python "$1" $2 >test.log
}
Saying python can not open the file /home/dev/src/crypto/util.py because there is no such file.
Any idea why?
Here is the output of the ll command on the directory/file:
drwxr--r--. 2 dev root 4096 Jun 11 18:56 crypto
-rwxr--r--. 1 dev root 4934 Jun 9 10:50 util.py
Output of ls -llid /home/
654084 drwxr-xr-x. 4 root root 4096 May 8 10:52 /home
Output of ls -lid /home/dev/
924265 drwxr--r--. 4 dev root 4096 Jun 9 09:17 /home/dev/
Output of ls -lid/home/dev/src/:
924266 drwxr--r--. 9 dev root 4096 Jun 9 10:01 /home/dev/src/
Output of ls -lid/home/dev/src/crypto:
924333 drwxr--r--. 2 dev root 4096 Jun 11 18:56 /home/dev/src/crypto/
Output of ls -lid/home/dev/src/crypto/util.py:
924337 -rwxr--r--. 1 dev root 4934 Jun 9 10:50 /home/dev/src/crypto/util.py
some of those dirs don't have x permission bit set - those are needed for entering a directory. Your problem may be that your scripts are running with another user as owner than "dev". dev is the only user allowed to change to those directories.
Set the dirs to +x, and try again.