DEV Community: Siddharth Pradhan

Understanding Root vs. Non-Root Users, Docker, and Fixing ECR Authentication Issues

Siddharth Pradhan — Sun, 09 Mar 2025 10:07:29 +0000

When working with Docker and cloud services like Amazon Elastic Container Registry (ECR), you may encounter issues related to user permissions and authentication. One common problem is the "authorization token has expired" error when pushing images to ECR. This error often arises due to differences between how root and non-root users interact with Docker and AWS ECR.

In this blog, we’ll cover:

Root vs. Non-Root Users in Linux and Docker
Why the ECR Authentication Token Expires
How to Fix the "Authorization Token Expired" Error
Best Practices for Managing Docker and ECR Authentication

Root vs. Non-Root Users in Linux and Docker

What is the Root User?

The root user is the superuser in Linux-based systems. It has unrestricted access to all commands, files, and system resources. When you run a command with sudo, you’re executing it as the root user.

Unlimited Privileges: The root user can perform any action on the system, including installing software, modifying system files, and changing permissions.
Dangerous Power: A single incorrect command as root can delete critical system files or render the system unusable.
Home Directory: The root user’s home directory is /root.
Configuration Files: Root-specific configurations are stored in /root/.docker/config.json (for Docker)

What is a Non-Root User?

A non-root user is a regular user with limited permissions. These users are created for everyday tasks and are restricted from performing administrative actions unless explicitly granted permission.

Limited Privileges: Non-root users can only access files and directories they own or have been granted permission to use.
Home Directory: Each non-root user has a home directory, typically located at /home/username.
Configuration Files: User-specific configurations are stored in /home/username/.docker/config.json (for Docker).
Security: Non-root users cannot modify system files or install software globally, which reduces the risk of accidental damage or security breaches.

Why Does Linux Distinguish Between Root and Non-Root Users?

The distinction between root and non-root users is a core part of Linux’s security model. Here’s why it’s done:

Security:

Minimize damage if a user’s account is compromised.
Follow the Principle of Least Privilege: Users are given only the permissions they need to perform their tasks.

Stability:

Prevent accidental changes to critical system files.
Isolate user files and configurations to avoid conflicts.

Accountability:

Actions performed by non-root users can be logged and audited.

2. Why the ECR Authentication Token Expires

Amazon ECR requires users to authenticate Docker before pushing or pulling images. This authentication is done using a temporary token generated by the AWS CLI command:


`aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com`

Key Points About the Token:

The token is valid for 12 hours by default.
The token is stored in the Docker configuration file (~/.docker/config.json) of the user who ran the docker login command.
If you switch users (e.g., use sudo to run Docker commands), the token from the non-root user’s configuration is not accessible, leading to the "authorization token expired" error.

3. How to Fix the "Authorization Token Expired" Error

The error occurs because the Docker client is unable to find a valid authentication token for ECR. Here’s how to fix it:

Option 1: Run Docker Commands Without sudo

If your user is part of the docker group, you can run Docker commands without sudo. This ensures that the Docker client uses the correct configuration and authentication token.

Add Your User to the docker Group:

`sudo usermod -aG docker $USER`

Log out and log back in, or run newgrp docker to apply the changes.

2.Authenticate Docker with ECR:

`aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com`

Push the Image:

`docker push <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/siddharth/test-lambda:latest
`

Option 2: Authenticate as Root

If you must use sudo, you need to authenticate Docker with ECR as the root user.

Switch to the Root User:

`sudo su`

Authenticate Docker with ECR:

`aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com`

Push the Image:

`
docker push <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/siddharth/test-lambda:latest`

Exit the Root Shell:

`exit`

Option 3: Use a Docker Credential Helper
To avoid manually logging in repeatedly, you can configure a Docker credential helper for ECR. This automatically manages your ECR credentials.

1.Install the Docker Credential Helper for ECR:

`sudo apt-get install docker-credential-helper-ecr`

Update Your Docker Configuration: Edit ~/.docker/config.json and add:


`{
  "credsStore": "ecr-login"
}`

Reauthenticate with ECR:

`aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com`

Push the Image:

`docker push <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/siddharth/test-lambda:latest`

4. Best Practices for Managing Docker and ECR Authentication

Avoid Using sudo with Docker:

Add your user to the docker group and run Docker commands as a non-root user.
This reduces security risks and avoids configuration mismatches.

Use a Credential Helper:

Configure the Docker credential helper for ECR to automate authentication and avoid token expiration issues.

Rotate AWS Credentials Regularly:

Ensure your AWS access keys are rotated periodically for security.

Monitor Token Expiry:

If you’re running long-running scripts, ensure the ECR token is refreshed before it expires.

Use IAM Roles for EC2 Instances:

If you’re working on an EC2 instance, assign an IAM role with ECR permissions to avoid managing access keys.

Final Thoughts: The Philosophy of Root and Non-Root

In the world of Linux, the root user is like a god—it can create, destroy, and reshape the system at will. But with great power comes great responsibility. One wrong move, and the entire system can come crashing down. On the other hand, the non-root user is like a wanderer—limited in scope but free to explore within boundaries. It’s a reminder that constraints aren’t always limitations; they’re often protections.

When you work with tools like Docker and ECR, you’re not just managing containers or pushing images—you’re navigating a system built on layers of trust, permissions, and balance. It’s a microcosm of how we should approach life: be bold, but not reckless; be free, but not careless.

So, as you dive deeper into the world of DevOps, remember this: The root user may have all the power, but the non-root user has all the wisdom. Use both wisely.

Stay Hungry, Stay Rooted
Keep breaking barriers, but always know your limits. Keep building, but always respect the system. And most importantly, keep learning—because in the end, the only thing that truly roots us is our curiosity.

Stay dope. Stay grounded. 🚀

Syncing Prisma Migrations: Aligning Your Schema Drift and Manual SQL Changes in PostgreSQL

Siddharth Pradhan — Fri, 28 Feb 2025 14:01:20 +0000

disclaimer: newbie here 1st time ever ran into this problem anyone reading this pls suggest some better methods

If you’ve been working with Prisma and PostgreSQL, you might run into a situation where your database schema and Prisma migration history are out of sync. This often happens when:

You make direct manual SQL changes instead of using Prisma migrations.
You create an enum and use it in the same migration (which PostgreSQL doesn’t allow).
You delete or modify migration files after they’ve been applied.
Prisma tries to reset the database because it detects drift.
Instead of resetting your database and losing data, I’ll walk you through how to sync your Prisma migrations with your actual PostgreSQL schema safely.

What is Schema Drift in Prisma?

Prisma tracks all applied migrations in a special table called _prisma_migrations. When you make direct SQL changes, Prisma isn’t aware of them, so it assumes your database is different from what it expects. This is called schema drift.

To check if your database is out of sync, run:

npx prisma migrate status

If you see something like "The database schema is not in sync with the migrations history", that means there’s a drift.

Step 1: Check Your Current Database Schema

First, you need to verify what your database schema looks like compared to your Prisma schema. Run:

npx prisma db pull

This command updates your schema.prisma file to reflect the current state of your PostgreSQL database. If there are changes that Prisma wasn’t tracking, you’ll see them here.

Now, compare your prisma/migrations folder with your schema.prisma. If you see differences, that means Prisma thinks some migrations haven’t been applied, or the database was changed manually.

Step 2: Identify and Remove Problematic Migrations

f Prisma thinks a migration is missing but you already applied the changes manually, you need to remove that migration from the _prisma_migrations table so Prisma stops trying to reapply it.

To list all applied migrations:

psql your_database -c "SELECT * FROM _prisma_migrations;"

Find the problematic migration name and delete it from the history.

To remove a specific migration:

DELETE FROM _prisma_migrations WHERE migration_name = '20240228000100_add_enum_and_table';

⚠️ Warning: Be very careful when deleting migrations! Always take a backup before making changes.

Step 3: Create and Apply a New Migration Without Resetting

Now that you’ve removed the problematic migration from Prisma’s history, you need to generate a new migration file that matches the current schema.

1️⃣ Run this command to create a new migration without applying it:

npx prisma migrate dev --create-only --name sync_schema

This generates a migration file inside prisma/migrations/, but it won’t run it yet.

2️⃣ Manually edit the migration file to make sure it accurately reflects your current schema.

3️⃣ Mark this migration as applied so Prisma won’t try to reapply changes:

npx prisma migrate resolve --applied "sync_schema"

Now, Prisma knows this migration is already applied and won’t try to reset your database.

Step 4: Verify That Everything is in Sync

Finally, check that Prisma recognizes your schema as up-to-date:

npx prisma migrate status

If everything is correct, you should see:

pgsql

Database schema is up to date!
To be extra sure, run:

npx prisma db pull

This ensures your schema.prisma is fully synced with the live database.

Best Practices to Avoid Schema Drift in Prisma
✅ Always use Prisma migrations instead of direct SQL changes.
✅ If you must make manual changes, immediately run prisma db pull to sync.
✅ Never modify an already applied migration file. Instead, create a new migration.
✅ Regularly check npx prisma migrate status to catch drift early.
✅ Use npx prisma migrate resolve instead of forcing resets to preserve data.