Gluster filesystem mount issue in LXC container

-
I was setting up a Gluster cluster file system in 2 LXC containers where I ran into an error.

Implementation process


1. Install gluster-server,

 in both containers:

 $ sudo apt-get install glusterfs-server

 2. Peer the gluster nodes,

 in container01:

 $ sudo gluster peer probe container02
peer probe: success

in container02:

 $ sudo gluster peer probe container01
peer probe: success

 3. Create the glusterfs manager folder,

 in both containers:

 $ sudo mkdir /gluster_data

4. Create vol1 volume,

in containers01:

$ sudo gluster volume create vol1 replica 2 transport tcp container01:/gluster_data container02:/gluster_data force
volume create: vol1: success: please start the volume to access data

 5. Start the volume,

 in container01:

 $ sudo gluster volume start vol1
volume start: vol1: success

6. Mount the newly created shared storage vol1:

$ sudo mkdir /pool1
$ sudo mount /pool1 

And here, when I tried to mount the vol1, i got following error:

[2015-12-12 21:19:37.277176] I [glusterfsd.c:1910:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.4.2 (/usr/sbin/glusterfs --volfile-id=/vol1 --volfile-server=container01 /pool1)
[2015-12-12 21:19:37.277756] E [mount.c:267:gf_fuse_mount] 0-glusterfs-fuse: cannot open /dev/fuse (No such file or directory)
[2015-12-12 21:19:37.277768] E [xlator.c:390:xlator_init] 0-fuse: Initialization of volume 'fuse' failed, review your volfile again

As per error it seems gluster looking for fuse device /dev/fuse which apparently isn't exist.

$ sudo ls /dev/fuse
ls: cannot access /dev/fuse: No such file or directory

Solution
To create the fuse device manually,

in both containers:

$ sudo mknod /dev/fuse c 10 229

Now try to mount again:

$ sudo mount /pool1 
$ df -h /pool1
Filesystem            Size  Used Avail Use% Mounted on
container01:/vol1     30G   26G  2.5G  92% /pool1

And if you want to make the mount boot persistent, add the following line in the /etc/fstab for each container respectively: 

$ cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
container01:/vol1 /pool1 glusterfs defaults,_netdev 0 0 



Comments

  1. sphjlc26 April 2017 at 10:16

    Thanks a lots! This really helpful!

    ReplyDelete
  2. Death essays11 April 2020 at 22:22

    The process is not difficult, and, as far as I can see, we can always ask your assistance. Hope to get proper answers.

    ReplyDelete

Post a Comment

Popular posts from this blog

Linux and AIX user non expiry and force password change at first login

-
In Linux, if you want to set the password for an account to never expire, here is the command: # chage -I -1 -m 0 -M 99999 -E -1 username  And to force a user to change his password upon first login: # chage -d0 username Current status of the account can be checked via chage command : # chage -l username  Last password change                                    : Jun 18, 2013 Password expires                                        : never Password inactive                                       : never Account expires                                         : never Minimum number of days between password change          : 0 Maximum number of days between password change          : 99999 Number of days of warning before password expires       : 7 For AIX, to set the password to non expiry and force the user to change his password upon first login: # chuser expires=0 maxage=0 username  To check the username status in AIX: # lsuser -f username
Read more

Rebuild your new Yum repository after changing the packages

-
If you have done any  changes  to your local  repository  packages, adding new ones or deleting some, you can just simply update your yum sqlite metadata database for your changes to take effect, rather than creating the whole repository again which takes time if you have  thousands  of packages in your repository.  Here is how we rebuild our yum repository. 1. After you are done with adding/removing packages to your local repo, then: # createrepo --update /path/to/repo_dir 2. On the  client  side, you need to clean up the cached yum meta data in order to see the changes after repo rebuild: # yum clean all 3. Now update the  client  yum cache  # yum update
Read more

Running Docker Wildfly/JBoss Application Server in Debug mode via Eclipse

-
I have recently built the whole Development Environment of Java Enterprise Edition (J2EE) project on multiple Docker containers. It has saved the hassle of setting up a dev env for new developers. All it takes to setup the environment is to clone our github repositories and run the Docker images. I will explain the setup in a future post. Build Wildfly Docker Image with Debugging Enabled So basically in order to run the Wildfly in debug mode, we need to add --debug  flag to the Wildfly standalone.sh  startup script. Also we need to expose port 8787  in our image as it's the default port for Wildfly JVM debug mode. 1. Create or change your Wildfly Dockerfile as follows: $ cat Dockerfile FROM jboss/wildfly: 10.0 . 0 .Final EXPOSE 8787 CMD [ "/opt/jboss/wildfly/bin/standalone.sh" , "-b" , "0.0.0.0" , "-bmanagement" , "0.0.0.0" , "--debug" ] 2. Build and tag the image: $ docker build -t wildfly-debug . 3.
Read more