Issue with CasaOS using storage manager

[Max]

Sorry I had to drive home. Do I do that in the PVE shell on proxmox or CasaOS console?

Thanks,

Max

[dragonfire1119]

You would do this in the Proxmox LXC console.

[Max]

After speaking in chat this really helped alot:

Max:

How do you know which nvme option it is?

Dragonfire1119:

You can identify the hard drive by the size or name ETC…: lsblk -f -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL

I was able to find the drives I want to add below and I have another question after the image:

The drive I have in the image below is the boot drive for proxmox and stores all my LXCs and VMs. Would I be able to mount it too or no?

The 6TB drives are my RAIDZ2 for Nextcloud so I am not messing with those! lol

[Max]

I did try to format the drive on my casaos console but it says “does not exist and no size was specified”.
I know you said to do a drive labeled “/dev/nvme1n1p1” but I did not see that listed.
Will it make a virtual disk inside of the physical disk and name it that or something when I mount it?
I am not sure I am fully understanding how the LXC container mounts a physical disk from the Proxmox host.

I appreciate the help!

[Max]

Okay, this may be the issue. The physical disk on proxmox has not been set up as a volume or directory under the “disks” section. I am unsure which option is necessary LVM, directory, or a ZFS? Which one will work for this setup???

[dragonfire1119]

The choice between LVM, directory, or ZFS for setting up a physical disk on Proxmox depends on several factors, including your specific needs for performance, flexibility, and data integrity. Here’s a brief overview of each to help you decide:

1. LVM (Logical Volume Manager):

• LVM is a flexible volume management system that allows you to easily resize volumes and manage multiple disks.
• It’s a good choice if you want the flexibility to resize your storage later or if you plan on using snapshots.
• LVM can be a bit more complex to manage than a simple directory but offers more features.

2. Directory:

• This is the simplest option where you mount a filesystem that is located on a partition directly.
• It’s easy to set up and understand, and it can be used on any filesystem supported by Linux.
• If you just want to store files without needing advanced features like snapshots or dynamic resizing, a directory is a straightforward choice.

3. ZFS:

• ZFS is an advanced filesystem that includes features like built-in snapshots, replication, compression, and integrity checking.
• It’s a good choice if data integrity and advanced filesystem features are a priority.
• ZFS can be more resource-intensive, and it’s recommended to use ECC RAM when running ZFS to prevent corruption.

If you don’t need the advanced features of ZFS or LVM, setting up a directory is the simplest and easiest approach. Here’s how you can do it:

1. Format the disk with ext4.
2. Mount the filesystem to a directory on the Proxmox host.
3. Use the mounted directory as a storage for your LXC containers.

[Max]

@dragonfire1119

2. Directory:

• This is the simplest option where you mount a filesystem that is located on a partition directly.
• It’s easy to set up and understand, and it can be used on any filesystem supported by Linux.
• If you just want to store files without needing advanced features like snapshots or dynamic resizing, a directory is a straightforward choice.

If you don’t need the advanced features of ZFS or LVM, setting up a directory is the simplest and easiest approach. Here’s how you can do it:

1. Format the disk with ext4.
2. Mount the filesystem to a directory on the Proxmox host.
3. Use the mounted directory as a storage for your LXC containers.

The directory seems like the best option as it’s straight-forward and mounts it to PVE. It also formats it to ext4 for me. As well, now I see the “nvme1n1p1” on the list for lsblk -f as seen below:

I will go through the steps you mentioned previously and see if it works in CasaOS now.

[dragonfire1119]

You will also, after mounting the drive on the host, need to mount the directory in the LXC.

Bind Mount the Directory to the LXC Container

You’ll need to edit the LXC container’s configuration file to set up the bind mount. The configuration file is usually located at /etc/pve/lxc/<vmid>.conf, where <vmid> is the ID of your LXC container.

You can add a line to the configuration file:

mp0: /mnt/data,mp=/data

This line means that the host directory /mnt/data will be mounted to /data inside the container.

You can add this line by editing the file with a text editor or by running the following command:

echo "mp0: /mnt/data,mp=/data" >> /etc/pve/lxc/<vmid>.conf

Make sure to replace <vmid> with the actual ID of your LXC container.

After this, restart the LXC container to apply the changes:

pct stop <vmid>
pct start <vmid>

Inside the container, you should now see the host’s /mnt/data directory mounted as /data.

[Max]

I successfully formatted both drives as ext4, creating them as directories and mounting them as “mp0” and “mp1.” Importantly, I didn’t overwrite the existing “DATA” folder. Instead, I organized the storage by adding two new folders: “256GB” for the NVME drive and “3TB” for the SATA 3.5-inch disk within the “DATA” directory. I find this naming convention straightforward and user-friendly.

Now, I’d like to set the 256GB NVME drive as the default location for AppData. If you have any guidance on how to achieve this, it would be greatly appreciated.

Additionally, I plan to use the extra 3TB drive as a Samba share for personal use. While I believe CasaOS offers straightforward Samba setup options, if you happen to know of a quick setup guide, I’d be more than happy to explore it.

Thank you for your assistance!

[dragonfire1119]

I wrote a tutorial on copying data and then mounting the drive to /DATA/AppData.

How to Migrate CasaOS Data to a New Drive and Mount It Permanently

When you’re upgrading your storage or adding additional space to your CasaOS setup, you’ll need to copy existing data to a temporary directory before mounting the new drive. This process involves identifying the new drive, formatting it, and ensuring all your data remains intact and accessible. Here’s a step-by-step guide to doing just that. Step 1: Identifying the New Drive Before you can format and mount your new drive, you need to identify it. The lsblk -f command is a simple way to do this: …

[Max]

@dragonfire1119

You will also, after mounting the drive on the host, need to mount the directory in the LXC.

Bind Mount the Directory to the LXC Container

You’ll need to edit the LXC container’s configuration file to set up the bind mount. The configuration file is usually located at /etc/pve/lxc/<vmid>.conf, where <vmid> is the ID of your LXC container.

You can add a line to the configuration file:

mp0: /mnt/data,mp=/data

This line means that the host directory /mnt/data will be mounted to /data inside the container.

You can add this line by editing the file with a text editor or by running the following command:

echo "mp0: /mnt/data,mp=/data" >> /etc/pve/lxc/<vmid>.conf

Make sure to replace <vmid> with the actual ID of your LXC container.

After this, restart the LXC container to apply the changes:

pct stop <vmid>
pct start <vmid>

Inside the container, you should now see the host’s /mnt/data directory mounted as /data.

Well, luckily there is no data right now so I can just mount it permanently. Would I just adjust the path inside the vmid.conf file for the mount points mp0 and mp1 like above or does it not work that way?

[dragonfire1119]

You need to mount it into the LXC:

Issue with CasaOS using storage manager

You will also, after mounting the drive on the host, need to mount the directory in the LXC. Bind Mount the Directory to the LXC Container You’ll need to edit the LXC container’s configuration file to set up the bind mount. The configuration file is usually located at /etc/pve/lxc/<vmid>.conf, where <vmid> is the ID of your LXC container. You can add a line to the configuration file: mp0: /mnt/data,mp=/data This line means that the host directory /mnt/data will be mounted to /data inside the…

Then mount it in the LXC with the LXC console.

How to Migrate CasaOS Data to a New Drive and Mount It Permanently

When you’re upgrading your storage or adding additional space to your CasaOS setup, you’ll need to copy existing data to a temporary directory before mounting the new drive. This process involves identifying the new drive, formatting it, and ensuring all your data remains intact and accessible. Here’s a step-by-step guide to doing just that. Step 1: Identifying the New Drive Before you can format and mount your new drive, you need to identify it. The lsblk -f command is a simple way to do this: …

[Max]

I’ve successfully mounted the drives to their designated folders in AppData. However, it seems that I need to configure permissions for read, write, and execute in order to create directories and install applications on them. I attempted to create a new directory and install an application but encountered some issues. Do you have any quick fixes or suggestions to help resolve this?

[dragonfire1119]

@Max

I’ve successfully mounted the drives to their designated folders in AppData. However, it seems that I need to configure permissions for read, write, and execute in order to create directories and install applications on them. I attempted to create a new directory and install an application but encountered some issues. Do you have any quick fixes or suggestions to help resolve this?

Could you post the errors that you’re getting?

[Max]

The mounted volumes have no permissions in Casa OS LXC.

I cannot give ownership to root and I cannot make directories in those mounted drives.

When I try to make a directory or install an app in the Casa OS GUI, nothing happens at all and I believe it’s related to this permissions issue.

Thanks!

Some errors from the cli below:

[dragonfire1119]

When you see nobody and nogroup as the owners of a directory or file within an LXC container, it typically means that there is a mismatch between the user IDs (UIDs) and group IDs (GIDs) on the host system and those inside the container.

1. User/Group Mismatch: The UIDs/GIDs on the host do not correspond to any valid user/group inside the container. This is common when UID/GID mapping is used for containers.

2. Permission Restrictions: The directory on the host has permissions that are too restrictive, preventing the container’s users from writing to it.

3. To find the UID and GID for a specific user, you can use the id command followed by the username. For example:

id username

This will give you an output like this:

uid=1000(username) gid=1000(usergroup) groups=1000(usergroup),...

Once you know the UID/GID that you want to have ownership inside the container, you can change the ownership on the host to match:

# Change to the UID/GID that corresponds to your container's user/group and the /mnt/data if needed.
sudo chown -R 1000:1000 /mnt/data

Replace 1000:1000 with the UID:GID that you need. The UID and GID should be the values that the container’s processes use.

[Max]

I get uid = 0 (root) gid =0 (root) group=0 (root).

The mounted drives have the proper permissions on the host:

root@pve:/mnt/pve# ls -l
total 8
drwxr-xr-x 9 root root 4096 Nov 7 16:29 NVME_256GB
drwxr-xr-x 8 root root 4096 Nov 7 00:09 SATA_3TB

[dragonfire1119]

Change Ownership to Match Container’s Mapped UID/GID

You can change the ownership of the mounted directories to match the mapped UID/GID of the container’s root user:

1. Find Mapped UID/GID: First, find out what UID/GID range is mapped to the container. This information is usually in the container’s configuration file located at /etc/pve/lxc/<vmid>.conf. Look for lines starting with lxc.idmap.
2. Change Ownership on Host: Use the chown command on the host to change the ownership of the directories to match the container’s mapped UID/GID.

For example, if the mapped UID for root in the container starts at 100000, you would do:

chown -R 100000:100000 /mnt/pve/NVME_256GB
chown -R 100000:100000 /mnt/pve/SATA_3TB

[Max]

I finally got the right permissions and can read/write/execute now. phew!
I had to find the id range to map and then once I did that in the vmid.conf it worked like a charm.
What a pain!! lol!

This was the mapping that worked for me:
lxc.id_map: u 0 100000 65536
lxc.id_map: g 0 100000 65536

I also did the chown -R 100000:65536 to the mounted directories on the host like so:

chown -R 100000:65536 /mnt/pve/NVME_256GB
chown -R 100000:65536 /mnt/pve/SATA_3TB

Once I did that the container would start up again and I was able to create and delete directories on those volumes /DATA/AppData/256GB and /DATA/AppData/3TB.

Issue resolved!

When I tried 100000:100000 it would not boot. I read that this mapping may not work if you have a lot of containers and that is likely the culprit to it not working since I have multiple.

[Max]

One thing I would like to note about this is that most of this stuff can be done on the GUI with proxmox outside of the lxc.idmap and the chown permissions change I think.

If you see below you can add directories to your physical disks in the GUI:

Note: It also gives the option for ext4 or xfs for formatting and I chose ext4.

Below you will see that you can go to the container “resources” and add the mountpoints there. You don’t need the CLI for this either:

For someone who is a visual learner, this was very helpful and better to understand in my experience.