Three Storage Locations with same % full

[kc8akw]

I have three storage locations on my system. All three are on independent drives.
Default should never get touched, except in the event of equipment failure. S1 is very active and gets written to almost constantly. S2 was added to offload most cameras from S1.

At some time, the S1 drive failed. I noted that when I started seeing it's fill at, say, 86%, S2 was at 7% and Default suddenly started growing. I could not salvage S1, so I added another drive. Because S2 used so much less space, I did the following:
un

• plugged the cameras
  set up the new drive to be S2
  copied all of S2 to the new drive
  Edited the fstab file to show the new UUID for S2 and move the assignment for S1 to the original S2 UUID
  Rebooted the system
  Plugged the cameras back in.
  
  Result: All of the storage locations currently show the same fill %.
  
  What am I missing?

[kc8akw]

New information to add:

Prior to the drive failure, I had in the fstab file the following entries:
UUID=7c6c1200-d024-487c-b5ae-784c1a411439 /media/S2/ ext4 noatime,nodiratime,nofail 0 0
UUID=9bab49ec-57dd-43a7-9d54-6d6ec5023b28 /media/S1/ ext4 noatime,nodiratime,nofail 0 0

Upon replacing the drive with a different drive and swapping to match drive to anticipated information needs:
#UUID=9bab49ec-57dd-43a7-9d54-6d6ec5023b28 /media/S1/ ext4 noatime,nodiratime,nofail 0 0
UUID=7c6c1200-d024-487c-b5ae-784c1a411439 /media/S1/ ext4 noatime,nodiratime,nofail 0 0
UUID=686CDD9C6CDD657A /media/S2/ ext4 noatime,nodiratime,nofail 0 0

Drives are being mounted at:
dev/sda1 /media/camera/S2 ext4 rw,nosuid,nodev,relatime,errors=remount-ro 0 0
/dev/sdb1 /media/camera/S1 ext4 rw,nosuid,nodev,relatime,errors=remount-ro 0 0

Using the file manager, I find that the /media/S1/events and the /media/S2/events folders show 242 GB available. That is the local hard drive.
/media/camera/S2 and /media/camera/S1 show the respective drive capacities.

[mikb]

UUID=7c6c1200-d024-487c-b5ae-784c1a411439 /media/S1/ ext4 noatime,nodiratime,nofail 0 0
UUID=686CDD9C6CDD657A /media/S2/ ext4 noatime,nodiratime,nofail 0 0

Drives are being mounted at:
dev/sda1 /media/camera/S2 ext4 rw,nosuid,nodev,relatime,errors=remount-ro 0 0
/dev/sdb1 /media/camera/S1 ext4 rw,nosuid,nodev,relatime,errors=remount-ro 0 0

That's not what your fstab is asking for though, is it? Something is ignoring (or overriding) your mount requests. So :-

Using the file manager, I find that the /media/S1/events and the /media/S2/events folders show 242 GB available. That is the local hard drive.

That would be correct, given what you've said. /media/S1 and /media/S2 seem to be just the mount _points_ which are on the underlying root filesystem. Nothing has been mounted on them.

/media/camera/S2 and /media/camera/S1 show the respective drive capacities.

So your requested mounts of /media/S1 and /media/S2 where the two drive should live are not being used. They are turning up at /media/camera/S1 and /media/camera/S2.

Solutions: Decide which one of these two mounting arrangements you want, and stick to just one -- either get them mounted in the RIGHT place. or live with where they are and get ZM to look in the right place ...

I don't know how you manage mounting filesystems etc. on your system, I manually put mine in /etc/fstab and ",noauto" any that I don't want to automatically mount at boot. E.g. removables/network attached that may not be/USB sticks ...

Look very closely at where the word "camera" has appeared/disappeared between what you stated you wanted with the UUID .... line and what seems to have actually been done.

Also, just double check that the UUID of the devices are EXACTLY what is stated in the fstab entry .. run "blkid" and look down the devices found for the declared UUIDs. If there's a discrepancy (even minor), those fstab lines might be just entirely ignored, on the basis "Well, if you ever attach something with _that_ UUID I'll bear it in mind", meanwhile "I'll just guess where to mount _this_ then!" ...

[kc8akw]

BINGO! I guess I should change my name to Thomas and take on the nickname of Doubting. I did not expect the UUIDs to change. The system worked prior to the failure of the drive. I simply reassigned one of the drives, so I expected that UUID to remain the same. What I left out was that I also reformatted both drives. So, I learned the UUIDs come from formatting and/or partitioning. They are not baked in like a MAC address.

The other thing that threw me was that Camera was the user account that was used to install Zoneminder. I was afraid that maybe it got set to auto login and that was throwing things.

Lessons learned. Many thanks!

[mikb]

reformatted both drives. So, I learned the UUIDs come from formatting and/or partitioning. They are not baked in like a MAC address.

Ah, good that you found it! The physical drive has a SERIAL number (you can see this in 'smartctl -a /dev/sdX') which should be unique across the manufacturer's run of drives. That's baked in the hardware (well, drive firmware I'd expect).

But the UUID is effectively a random number, so big that the chances of you seeing that number on any other drive/partition in your system, network, or probably _lifetime_ is effectively zero!

Yes, it is generated when you partition the drive (there is a drive UUID) and another is created for each partition (PART-UUID) and when clone a drive, it is copied over. This may be a good thing (if you want a drop in replacement) or a bad thing (in which case you need to set a new UUID to separate the original from the clone).

[dougmccrary]

I got tired of messing with UUIDs and started using LABEL. Much simpler.