Learn how K8s is uniquely suited for supporting machine learning, how to use it to make your ML pipelines run faster and better, and tools for ETL and ML.

Five principles that will convince you that Kubernetes is currently the best technology for running a Cloud-Native database and how it will continue to mature.

Encountered a ‘Permission Denied’ error on a file copied to a Docker image or when accessing a file on a mounted volume within a Docker container? In this blog, you will learn why you get a ‘Permission Denied’ error and how to solve it. Enjoy! 1. Introduction Before diving into the Permission Denied problem within Docker containers, it is good to have a basic knowledge how permissions function in Linux. If you are already familiar with these concepts, you can skip this paragraph. A good starting point for getting acquainted with permissions can be found at the Ubuntu documentation and this excellent explanation about umask. If you want a quick summary, read on! When you create a new directory blog and list the properties of that directory, you will see the following output in a terminal window: Shell $ mkdir blog $ ls -la drwxrwxr-x 2 user group 4096 Aug 14 06:15 blog/ Let’s examine some items which are listed here from left to right: d Indicates this is a directory. rwx The owner’s permissions. In this case, the owner has read, write and execute permissions. rwx The group’s permissions. A user belongs to one or more groups. In this case, the permissions are identical as for the owner. r-x The other’s permissions. Anyone else, not being the owner or not belonging to the group, will have in this case read and execute permissions. user The directory is owned by this user. Under the hood, this logical name is mapped to a user id (uid). When you have only one user, this will probably be uid 1000. group The directory is owned by this group. Under the hood, this logical name is mapped to a group id (gid). Your gid will probably be gid 1000. When you create a new file defaultpermissions.txt and list the properties of the file, you will see a similar output: Shell $ touch defaultfilepermissions.txt $ ls -la -rw-rw-r-- 1 user group 0 Aug 14 06:20 defaultfilepermissions.txt The permissions are listed in a similar way as for the directory. There is no d as first item because it is not a directory of course and the file does not have any execute permissions. 2. Prerequisites The tests executed in the following paragraphs are executed from within a VirtualBox Virtual Machine (VM) based on Ubuntu 22.04 provided by osboxes.org. This can easily be setup if you follow the instructions in paragraph 2 of a previous post. Once logged in into the VM, docker needs to be installed. At the time of writing, Docker v20.10.14 is used. Shell $ sudo snap install docker You can also execute the tests from you own local installation of Ubuntu, no changes to your system settings are required for executing the tests. When using the OSBoxes VM, the user/group will be osboxes/osboxes. If you are using your own system, the user/group can be retrieved by using the users and groups command. The files used in the paragraphs below are available at GitHub. 3. Container Running as Root In this first test, a file will be copied from the local file system to the Docker image. The base image for the Docker image is the Alpine Linux image. Create a directory 1-defaultcontainer, navigate to the directory and create a test.txt file with some dummy contents. Create a Dockerfile in the same directory with the following contents: Plain Text FROM alpine:3.16.2 COPY test.txt /tmp/test.txt The FROM instruction will use the Alpine Linux 3.16.2 base Docker image and the COPY instruction will copy the local test.txt file into the Docker image at location /tmp/test.txt. From a terminal window, build the Docker image: Shell $ sudo docker build -f Dockerfile -t dockertest . [sudo] password for osboxes: Sending build context to Docker daemon 3.072kB Step 1/2 : FROM alpine:3.16.2 3.16.2: Pulling from library/alpine 213ec9aee27d: Pull complete Digest: sha256:bc41182d7ef5ffc53a40b044e725193bc10142a1243f395ee852a8d9730fc2ad Status: Downloaded newer image for alpine:3.16.2 ---> 9c6f07244728 Step 2/2 : COPY test.txt /tmp/test.txt ---> 842ef14a6a73 Successfully built 842ef14a6a73 Successfully tagged dockertest:latest Start the Docker container with interactive mode in order to be able to use the shell: Shell $ sudo docker run --rm -it dockertest /bin/sh Navigate to directory /tmp and list the files: Shell # ls -la -rw-rw-r-- 1 root root 23 Aug 14 10:33 test.txt Notice that the file permissions are preserved, but the user/group is root/root. By default, a Docker container runs as the root user which is a security concern. Try to execute cat test.txt and you will notice that the contents of the file are output. Try to edit the file by means of vi and save the file. This action is also allowed. These results are logical: the root user executes them and root can do anything. Exit the shell by typing exit. In order to ensure that the tests are executed independently from each other, remove the Docker image as follows: Shell $ sudo docker rmi dockertest 4. Container Running as User 1000 This test is similar as the first one, except that you will create a user for the Docker container. This way, the container will not run anymore as the root user, which is a more secure way for running a container. Create a directory 2-containeruser1000, navigate to the directory and create a test.txt file with some dummy contents. Create a Dockerfile in the same directory with the following contents: Dockerfile FROM alpine:3.16.2 RUN addgroup --g 1000 groupcontainer RUN adduser -u 1000 -G groupcontainer -h /home/containeruser -D containeruser USER containeruser COPY test.txt /home/containeruser/test.txt What is happening in this new Dockerfile? With RUN addgroup, a group groupcontainer is created with gid 1000; With RUN adduser, a user containeruser is created with uid 1000, belonging to group groupcontainer and home directory /home/containeruser; With USER containeruser, the container runs with user containeruser; The local test.txt file is copied to the home directory of containeruser. This Dockerfile can be made more efficient in order to reduce the number of layers. For more information about layers, read a previous post about this topic. For sake of simplicity, optimizing the Docker image is not considered here. Build and run the container just like you did before. First check which user is running the container: Shell # whoami containeruser As expected, the container runs as user containeruser. Navigate to the home directory of containeruser and list the files: Shell # ls -la -rw-rw-r-- 1 root root 23 Aug 14 10:58 test.txt This might surprise you, but the owner of the file is still root/root. Try to execute cat test.txt and you will notice that the contents of the file are output. This can be done because other has read permissions. Remember, the container runs as user containeruser now. Try to edit the file with vi and save the file. This is not possible: a warning is raised that the file is read-only. That is because other does not have write permissions. When you are still not convinced, execute the same test but with uid/gid 1024. The results are the same. The files are available in the repository in directory 3-containeruser1024. Below the corresponding Dockerfile: Dockerfile FROM alpine:3.16.2 RUN addgroup --g 1024 groupcontainer RUN adduser -u 1024 -G groupcontainer -h /home/containeruser -D containeruser USER containeruser COPY test.txt /home/containeruser/test.txt Remove the Docker image. 5. Container Running as User 1024 and Changed Ownership In this paragraph, you will solve the permission issue. The trick is to change the ownership of the file to the user running the Docker container. Create a directory 4-containeruser1024changedowner. The Dockerfile is: Dockerfile FROM alpine:3.16.2 RUN addgroup --g 1024 groupcontainer RUN adduser -u 1024 -G groupcontainer -h /home/containeruser -D containeruser USER containeruser COPY --chown=containeruser:groupcontainer test.txt /home/containeruser/test.txt In the line containing COPY, the ownership of the test.txt file is changed to user containeruser and group groupcontainer. Build and run the container just like you did before. Navigate to the home directory of user containeruser and list the files: Shell # ls -la -rw-rw-r-- 1 containe groupcon 23 Aug 14 10:58 test.txt Try to execute cat test.txt and you will notice that the contents of the file are output. Try to edit the file with vi and save the file. This is allowed, because this time, containeruser owns the file and has the proper write permissions. Remove the Docker image. 6. Volume Mappings With volume mappings, you will map a local directory to a directory inside the Docker container. This can be more tricky, because you must make some assumptions about the local system permissions, users, groups, etc. And often this just works fine because your local uid/gid is probably 1000/1000 and inside the container this will be similar. With volume mappings, it is important that the uid/gid of the owner is identical outside and inside the container. Let’s see how this works! Create a directory 5-volumemapping and create a directory testdir and a test.txt file with some dummy contents inside this directory. Check the uid/gid of your local user: Shell $ id -u osboxes 1000 $ id -g osboxes 1000 The permissions of the directory are: Shell $ ll drwxrwxr-x 2 osboxes osboxes 4096 Aug 14 04:19 testdir/ The permissions of the file are: Shell $ ll -rw-rw-r-- 1 osboxes osboxes 23 Aug 14 06:58 test.txt This time, you use the following Dockerfile: Dockerfile FROM alpine:3.16.2 RUN addgroup --g 1024 groupcontainer RUN adduser -u 1024 -G groupcontainer -h /home/containeruser -D containeruser USER containeruser RUN mkdir /home/containeruser/testdir Notice that for the test it is important that the uid/gid of your local user and the user inside the container are different. You do not copy the file this time to the container, but with RUN mkdir, you ensure that a directory exists where the local volume can be mapped to. Build the Docker image as before and run the container from inside directory 5-volumemapping as follows. The -v parameter will mount the local testdir directory to the testdir directory into the home directory of user containeruser. Shell $ sudo docker run -v $(pwd)/testdir:/home/containeruser/testdir --rm -it dockertest /bin/sh Navigate to directory /home/containeruser and list the contents: Shell # ls -la drwxrwxr-x 2 1000 1000 4096 Aug 14 10:23 testdir As you can see, the uid/gid has the values 1000/1000 which is the uid/gid of the local system user who has created the directory. Navigate to directory testdir and list the contents: Shell # ls -la -rw-rw-r-- 1 1000 1000 23 Aug 14 10:23 test.txt Again, you notice the same ownership for the file as for the directory. Try to read the contents of file test.txt, this succeeds. Try to create a new file test2.txt, this returns a Permission Denied error because other does not have write permissions in this directory. Shell # cat test.txt this is a test message # touch test2.txt touch: test2.txt: Permission denied How to solve this, is excellently explained in this blog. Change the ownership of the directory in order that group 1024 has the ownership on the local system. Shell $ sudo chown :1024 testdir/ Ensure that new files get the group ownership. Shell $ chmod g+s testdir/ Check the directory permissions from inside the container of directory testdir: Shell # ls -la drwxrwxr-x 2 1000 groupcon 4096 Aug 12 10:23 testdir Now you notice that the group groupcontainer has ownership of this directory. Navigate to directory testdir, create a file, edit it with vi and output the contents. All of this is possible now. Shell # touch test2.txt # vi test2.txt # cat test2.txt another test message Check the permissions of the files. Shell # ls -la -rw-rw-r-- 1 1000 1000 23 Aug 14 10:23 test.txt -rw-r--r-- 1 containe groupcon 0 Aug 14 10:37 test2.txt The file test.txt still has its original ownership for uid/gid 1000/1000, the new test2.txt file has ownership for containeruser/groupcontainer. From the local system, it will be possible to read the contents of test2.txt, but it will not be allowed to change its contents due to the read-only permissions for other. Depending on your use case, several solutions exist how to solve this as described in the mentioned blog post. Remove the Docker image. 7. Conclusion Permission Denied errors when copying files into Docker images can be easily solved within the Dockerfile. Just follow the provided solution described in this blog. Permission Denied errors with volume mappings between a local directory and a directory inside the container can be a bit more tricky. Hopefully, the information provided in this blog will help you understand and solve the Permission Denied errors.

Take a look at CI/CD approaches in a Kubernetes ecosystem, best practices for implementing an efficient CI/CD framework, and popular open-source CI/CD tools.

This article attempts to list and compare the options to Elastic Beanstalk that can help you solve your growing scale.

In this article, learn how deploying microservices using Kubernetes enhances and enforces key principles and patterns while offering additional benefits.

GitOps extends the functionality of IaC by allowing developers to declare every resource in Git and automatically maintain the desired state across the infrastructure.

Containers generate huge volumes of log data. In a production environment, SREs, DevOps folks need a central location to query and analyse these logs, to do their job well. In this post we look at Parseable, a simple, efficient log observability platform that lets you store logs efficiently and query the logs easily to fix real world problems.

This guide breaks down the key concepts underlying Helm's structure and walks through some best practices.

Explore how implementing the right tools and standards for cloud-native observability can save your business valuable time and resources.

In this article, see why Kubernetes is a must-adopt cloud-native tool for businesses and how it helps them speed up their software deployment.

Explore how Kubernetes is becoming a new server for serverless architecture as we look at a few of its established enterprise patterns and buzzing use cases.

What is an Operator and why did we create one for IBM App Connect?

Take look at architecture-level choices being made and share the open standards with the open-source landscape.

Learn about a new framework that allows processing methods asynchronously with retries in case of failure and the support of load-balancing and failover.

This tutorial explains how to install the IBM App Connect Operator on an Amazon EKS cluster and deploy an integration using it.

Ever wonder how Kubernetes would handle a 1000-nodes Cassandra cluster?

Getting Docker working as a local network host on Windows requires quite a lot of kludgy hodgepodge of hacks to work, but it can be done.

This article will show how to expose an application using the service type load balancer.

a recent study by gartner predicts a very significant increase in cloud usage by consumers in a few years, due in great part to the ever growing use of smartphone cameras by the average household. in this context, it could be useful to have a smartphone application that is able to upload / download digital content from a cloud provider. in this article, we will construct a basic android prototype that will allow us to plug in the windows azure cloud provider, and use the windows azure toolkit for android ( available at github ) to do all of the basic cloud operations : upload content to cloud storage, browse the storage, download or delete files in cloud storage. once those operations are implemented, we will see how to enable our android application to receive server push notifications . first things first, we need to set up a storage account in the azure cloud: a storage account comes with several options as for data management : we can keep data in blob, table or queue storage. in this article, we will use the blob storage to work with images. the storage account has a primary and secondary access key , either one of the two can be used to execute operations on the storage account. any of those keys can be regenerated if compromised. 1. preliminaries first, the prerequisites: eclipse ide for java android plugin for eclipse ( adt ) windows azure toolkit for android windows azure subscription (you can get a 90-day free trial ) a getting-started document on windows azure toolkit’s github page covers the installation procedure of all the the required software in detail. this whole project ( cloid ) is freely available at github . so here we’ll limit ourselves to presenting the most relevant code sections along with the corresponding screens. the user interface is composed of a few basic activity screens, spawned from the main screen (top center): since we use a technology not for its own sake but according to our needs, let’s start by specifying what we want: public abstract class storage { /** all providers will have accesss to context*/ protected context context; /** all providers will have accesss to sharedpreferences */ protected cloudpreferences prefs; /** all downloads from providers will be saved on sd card */ protected string download_path = "/sdcard/dcim/camera/"; /** * @throws operationexception * */ public storage(context ctx) throws operationexception { context = ctx; prefs = new cloudpreferences(ctx); } /** * @throws operationexception * */ public abstract void uploadtostorage(string file_path) throws operationexception; /** * @throws operationexception * */ public abstract void downloadfromstorage(string file_name) throws operationexception; /** * @throws operationexception * */ public abstract void browsestorage() throws operationexception; /** * @throws operationexception * */ public abstract void deleteinstorage(string file_name) throws operationexception; } the above is the contract that our cloud storage provider will satisfy. we’ll provide a mockstorage implementation that will pretend to carry out a command in order to test our ui (i.e. our scrollable items list, progress bar, exception messages, etc.), so that we can later just plug in azure storage operations. note from our activities screen above, that we can switch anytime between azure storage and mock storage with the press of the toggle button “cloud on/off” in the settings screen, saving the preferences afterward. public class mockstorage extends storage { // code here... @override public void uploadtostorage(string file_path) throws operationexception { donothingbutsleep(); //throw new operationexception( "test error message", // new throwable("reason: upload test") ); } // other methods will also do nothing but sleep... /***/ private void donothingbutsleep(){ try{ thread.sleep(5000l); } catch (interruptedexception iex){ return; } } 2. the azure toolkit the toolkit comes with a sample application called “simple”, and two library jars: access control for android.jar in the wa-toolkit-android\library\accesscontrol\bin folder azure storage for android.jar in the wa-toolkit-android\library\storage\bin folder here we will only use the latter, since we will access directly azure’s blob storage. needless to say, this is not the recommended way , since our credentials will be stored on the handset. a better approach security-wise would be to access azure storage through web services hosted on either azure or other public/private clouds. once the toolkit is ready for use, we need to think a bit about settings . using an azure blob storage only requires 3 fields: an account name , an access key , and a container for our images. the access key is quite a long string (88 characters) and is kind of a pain to type, so one way to do the setup is to configure the android res/values/strings.xml file to set the default values: ... cloid insert-access-key-here pictures ... however, because we may want to overwrite the default values above (e.g. create another container), we will also save the values on the settings screen in android’s sharedpreferences . and now, let’s implement the azurestorage class. 3. azure blob storage operations 3.1. storage initialization the azurestorage constructor gets its data from android preferences (from its superclass), then constructs a connection string used to access the storage account, creates a blob client and retrieves a reference to the container of images. if the user changed the default container “pictures” in settings, then a new (empty) one will be created with that new name. a container is any grouping of blobs under a name. no blob exists outside of a container. // package here // other imports import com.windowsazure.samples.android.storageclient.blobproperties; import com.windowsazure.samples.android.storageclient.cloudblob; import com.windowsazure.samples.android.storageclient.cloudblobclient; import com.windowsazure.samples.android.storageclient.cloudblobcontainer; import com.windowsazure.samples.android.storageclient.cloudblockblob; import com.windowsazure.samples.android.storageclient.cloudstorageaccount; public class azurestorage extends storage { private cloudblobcontainer container; / * @throws operationexception * */ public azurestorage(context ctx) throws operationexception { super(ctx); // set from prefs string acct_name = prefs.getaccountname(); string access_key = prefs.getaccesskey(); // get connection string string storageconn = "defaultendpointsprotocol=http;" + "accountname=" + acct_name + ";accountkey=" + access_key; // get cloudblobcontainer try { // retrieve storage account from storageconn cloudstorageaccount storageaccount = cloudstorageaccount.parse(conn); // create the blob client // to get reference objects for containers and blobs cloudblobclient blobclient = storageaccount.createcloudblobclient(); // retrieve reference to a previously created container container = blobclient.getcontainerreference( prefs.getcontainer() ); container.createifnotexist(); } catch (exception e) { throw new operationexception("error from initblob: " + e.getmessage(), e); } } // code... we will use that container reference cloudblobcontainer throughout our upcoming cloud operations. 3.2. uploading images we will upload a file from android’s gallery to the cloud, keeping the same filename. “screener” is just a utilities class (see github repository) that does a number of useful things, e.g. extracting a file name from its path and setting the right mime type (“image/jpeg”, “image/png”, etc.). the two kinds of blobs are page blobs and block blobs . the (very) short story is that page blobs are optimized for read & write operations, while block blobs let us upload large files efficiently. in particular we can upload multiple blocks in parallel to decrease upload time. here we are uploading a blob (gallery image) as a set of blocks. /** * @throws operationexception */ @override public void uploadtostorage(string file_path) throws operationexception { try { // create or overwrite blob with contents from a local file // use same name than in local storage cloudblockblob blob = container.getblockblobreference( screener.getnamefrompath(file_path) ); file source = new file(file_path); blob.upload( new fileinputstream(source), source.length() ); blob.getproperties().contenttype = screener.getimagemimetype(file_path); blob.uploadproperties(); } catch (exception e) { throw new operationexception("error from uploadtostorage: " + e.getmessage(), e); } } bear in mind that we are not checking if the file already exists in cloud storage. therefore we will overwrite any existing file with the same name as the one we are uploading. that is usually not desirable in production code. here’s the screen flow of the upload operation: 3.3. browsing the cloud for browsing, we store all our blobs in our container into a list of items that we will display in android as a scrollable list of image names in a subclass of android.app.listactivity . once one item in the list is clicked (“touched”) by the user, we want to display some image properties such as the image size (important when deciding to download), its mime type, and the date it was last operated upon. /** * @throws operationexception * */ @override public void browsestorage() throws operationexception{ // reset uri list for refresh - no caching item.itemlist.clear(); // loop over blobs within the container try { for (cloudblob blob : container.listblobs()) { blob.downloadattributes(); blobproperties props = blob.getproperties(); long ksize = props.length/1024; string type = props.contenttype; date lastmodified = props.lastmodified; item item = new item(blob.geturi(), blob.getname(), ksize, type, lastmodified); item.itemlist.add(item); } // end loop } catch (exception e) { throw new operationexception("error from browsestorage: " + e.getmessage(), e); } } here’s the screen flow of the browse operation. pressing on an item on the list displays its details and operations on the image, which we will look at next: 3.4. downloading images our download method is pretty straightforward. note that we are downloading to the android handset’s sd card by using download_path from the superclass. /** * @throws operationexception * */ @override public void downloadfromstorage(string file_name) throws operationexception{ try { for (cloudblob blob : container.listblobs()) { // download the item and save it to a file with the same name as arg if(blob.getname().equals(file_name)){ blob.download( new fileoutputstream(download_path + blob.getname()) ); break; } } } catch (exception e) { throw new operationexception("error from downloadfromstorage: " + e.getmessage(), e); } } and the corresponding ui flow. instead of displaying the image right after the download, we chose to include a link to the gallery (bottom of the screen) where the freshly retrieved image appears on top of the gallery’s stack of pictures: 3.5. deleting images the delete operation performed on a blob up in the cloud is also rather simple: /** * @throws operationexception */ @override public void deleteinstorage(string file_name) throws operationexception{ try { // retrieve reference to a blob named file_name cloudblockblob blob = container.getblockblobreference(file_name); // delete the blob blob.delete(); } catch (exception e) { throw new operationexception("error from deleteinstorage: " + e.getmessage(), e); } } and its associated ui screens series. note that after confirming the operation, and when deletion completes, the browsing list of items is automatically refreshed, and we can see that the image is no longer on the list of blobs in our storage container. 3.6. wrapping up the azurestorage methods are called inside a basic work thread, which will take care of all cloud operations: // called inside a thread try { // get storage instance from factory storage store = storagefactory.getstorageinstance(this, storagefactory.provider.azure_storage); // for the progress bar incrementworkcount(); // do ops switch(operation){ case upload : store.uploadtostorage(path); break; case browse : store.browsestorage(); break; case download : store.downloadfromstorage(path); // refresh gallery sendbroadcast( new intent( intent.action_media_mounted, uri.parse("file://"+ environment.getexternalstoragedirectory()) ) ); break; case delete : store.deleteinstorage(path); break; } // end switch } catch (operationexception e) { recorderror(e); } notice how we are telling the android image gallery to refresh by issuing a broadcast once a new file is downloaded from the cloud to the sd card. there are different ways to do this, but without that call, the gallery won’t show the new image before the next system scheduled media scan. again, for the full code, refer to this project on github. we are done with the basic cloud operations. all we had to do was plug in our azurestorage implementation class and get an instance of it through a factory, with minimal impact on preexisting code. 4. push notifications up to this point we have demonstrated device-initiated communication with the cloud. for cloud-initiated or push communication, the android platform uses google cloud messaging (gcm). in a previous article , i wrote about how to integrate gcm into an existing android application. here we will add a second set of settings for server push. our client code will connect with any gcm server and it will set the status on our main activity (last screen shot on the right) once the information in push preferences is correctly set. 5. conclusions the toolkit documentation is kind of sparse (which is why the community needs more articles like this). also, the sample application doesn’t cover much (maybe the reason why it’s called “simple”), and it has room for improvement. however, the library itself is fully functional, and once we figure out the api, it all works quite nicely. of course, this application is itself pretty basic and doesn’t cover lots of other features, like access control, permissions, metadata, and snapshots. but it is a start.