Migrating OSX Monterey Stickies on an old Mac to Mac Tahoe

 I probably went about this wrong. Again.

Anyway, this post is about migrating ONE THING: the Stickies data, without doing a pile of new-sticky/copy/paste. Yeesh. This was painful last time...

Am migrating from Monterey to Tahoe. Reason: Monterey machine has been crashing a bunch. HARD crash that reboots. i.e., time for a new machine.

Found a great one on EBay, 60 miles away, so I drove to pick it up.

This project doesn't have a standard export/import behavior, which is stupid.

So where are the Stickies notes on Monterey?

~/Library/Containers/Stickies/Data/Library/Stickies/*

You need to archive that folder. OSX really does not want to let you see that folder.

Get to Finder, then command-shift-G, enter Library, which gets you started. You can find Containers in the list, then Stickies, etc.

Click right on "Stickies" and then "Compress Stickies" in the popup. Now drag the resulting Stickies.zip files over to a location like "DropBox" where you can do a casual share.

Copy that zip to the new machine (Tahoe, in my case).

cd ~/Library/Containers/com.apple.Stickies/Data/Library

(I don't know why that background turned black there)

copy Stickies.zip into the current folder, then

unzip Stickies.zip

Now you can open the Stickies app and poof! All your stickies notes are back, just like you had them before.

Seaweed diagrams and deployment design

 Drew this with excalidraw.com

https://excalidraw.com/#room=b4079384303e8f90b29b,0vxIFQUQ58Pw7lsfke-FBw

That was my initial deployment concept. Run each Volume Mgr instance in a VM. Mount one 16TB drive into each.

It also turns out that Seaweed has an 8TB limit on volume size, so those nice 16T drives aren't usable properly here.

Turns out the VM aspect isn't important. Can run 4 Volume Mgrs directly on the host OS. Regrettably, this is also incomplete, you need at least one more process, either "Filer" or "S3". (S3 apparently runs a Filer on the inside, but integrated.)

My suspicion right now is that I am doing this Volume Manager thing wrong, that you only want one per machine, and that it can handle multiple disks/folder as volumes. I don't know how you do this, yet.

In order to do anything interesting in terms of data, using S3, you will have to use the "SHELL" process also. This is how you create users (owners) and buckets. I have hunted for separate GUI tools, but haven't been impressed with what I saw; I would like to not have to create my own, but that may end up being what happens.

Data Center -- Installing and Configuring AWS S3 alternatives to be S3 services for internal/external use

My intention is to try out several of these tools. No preference yet. Those I expect to try out: Seaweed FS, RustFS, Garage, LocalStack. (MinIO seems off the table now)

-----

Seaweed FS

 The installation is trivial. Download the tgz file, unzip it, untar the resulting file wherever you want. 

Then there's the startup command:

AWS_ACCESS_KEY_ID=admin \
AWS_SECRET_ACCESS_KEY=secret \
S3_BUCKET=my-bucket \ 
./weed mini -dir=/data

(-dir=/where/the/data/should/go)

This starts the service with some defaults for a tiny space. ("mini")

Make sure that "/data" exists with proper permissions.

I did the install on an HP DL380 Gen 7 with Ubuntu 25 Server. It's not a super-powered machine, but this is just "mini". Will use bigger machine shortly.

This is just for test purposes, you don't want to try to do anything serious/real with "mini". You want to kick the tires. Partly because those are TERRIBLE credentials, and partly because this starts up with a 30GB max space. Kick the tires.

There are multiple web-page interfaces for it:

Obv of course you should use the IP of the server instead of "localhost".

There are some config files to work with on this. The web interface is a lot better at showing you things than it is at letting you change them.

Filer UI is like DropBox in terms of casual file storage in a folder hierarchy. This is the first part I tested. 

Basically I just wanted to see if this did what I was expecting, which it did.

The "Admin/Dashboard" is pretty busy.

To do some REAL work, a REAL system, use "master" instead of "mini": 

./weed master

That's the big one. Also: do this on a machine with a bunch of storage. I am arranging that shortly.

On other machines, you want to also install Seaweed FS, but you will use "volume" instead of "master".

./weed volume -dir="other/machine/file/space/" -max=10 -master="192.168.1.29:9333"

---------------------------------------------------

First step was to configure hardware. See "underlaying steps", below, for details. This was non-trivial, but entirely separate from Seaweed.

Second step was install Proxmox as host OS. This is straightforward, I have done this probably 25 times now. This is using Proxmox 9.2, the latest as of this writing.

Next step was to create the VMs. In Proxmox I created one, converted it to a template, and then created the rest of them. I forgot that I needed to do some work before turning it into a template. Always you do 

sudo apt update

sudo apt upgrade

which I did, but I forgot about setting static IPs on there. You have to fix each VM anyway, but if you do the template first, it's a lot easier. I also should have downloaded seaweed into the original before making the template. Oh well, all set now.

I also set the VMs to auto-start at boot time. I don't want to be doing that by hand ever again. I wish the Proxmox default had that turned on.

Having configured the hardware with big disks, I downloaded Seaweed onto all the VMs. I used "linux-full-amd64.tar.gz". That unpacks into a single executable that is the entirety of Seaweed.

Next I started seaweed.

./weed master

then i looked at the web-page for it, at swhost:9333, which doesn't work. Need to do a total reboot.

Now we are good:

OK. Halt 'weed'. Then 'sudo mv weed /usr/local/bin/'

Now need to do setup for seaweed to auto-start at reboot. It would be better to do this via systemctl, but I didn't get that to work for some reason. I used crontab in the end, with 

@reboot weed master

Reboot a couple times just to be sure, and all is good.

---------------------------------------------------------------

There are some underlying steps you need to make, configuring the hardware and VMs.

The hardware arrangement I have for testing is a single server with 4x16TB HDD. I wondered about how to RAID them, with a 1+0 being the most obvious, but also the most space-wasteful. Other choices like R6 weren't really any better, with only 4 drives. Someone suggested I go with a different approach, where Seaweed itself is providing the redundancy.

This was my original thinking:

One VM runs SW Master. Four VMs run SW Volumes. Configure SW for the amount of redundancy desired, and you have a total a 64 TB

Here's how to configure the host and the VMs. Took a while to get the right info, watch the right videos, deal with the ESL accents.

<picture>

The machine: 1 HP DL 360 G9 4 LFF 128 GB RAM 2x 2640 CPU, + 2x512GB SSD + 2x128GB SSD.

It has a fiber card too, which is not relevant to this writeup:

(Interestingly, this machine includes an internal SSD cage for 4 SSDs. I had two pairs of matching SSDs, so they are /dev/sda (2x512GB)  and /dev/sdb (2x128GB), both configured as RAID 1, where "sda" holds the host OS. I had never seen this cage before.)

The blue are the top two SSDs. There's another pair underneath. This takes special SATA cables to use them, for both power and data. I imagine those come with the cage. The silver cables are data, if you trace them out you can see they plug into the RAID controller. The data cable looks standard, I think I have a couple more of them acquired elsewhere for a different reason; the power cable looks custom to this machine.

The host OS here is ProxMox, so that I can create these VMs all on this one machine. IRL, in the Data Center, I wouldn't do that, each Master and Volume would be separate machines, with Seaweed running in the host OS, not a VM. Probably doing that soon.

But for this investigation...VMs.

Once Proxmox is installed you are going to create 5 VMs. These VMs are going to live inside the 512GB RAID volume, so they need to be no bigger than 80GB when you create them. This is a standard procedure with Prox, not covered here.

Once that is done, using Ubuntu 24 as their OS, need to tell Prox how to make the 16T disks available.

This is done by using the DISK ID rather than "/dev/sdc" names, lest an accident of timing during boot shift those around a little. 

At the command line:

ls -n /dev/disk/by-id/ <return>

and you get this (and probably a lot more)

lrwxrwxrwx 1 0 0  9 May 27 08:02 scsi-3600508b1001c710b4c7493cf3630fb6f -> ../../sdc

lrwxrwxrwx 1 0 0  9 May 27 08:02 scsi-3600508b1001cd17c6f7fea6ce6d097d5 -> ../../sdd

lrwxrwxrwx 1 0 0  9 May 27 08:02 scsi-3600508b1001cc9fc14dafef1c4174c23 -> ../../sde

lrwxrwxrwx 1 0 0  9 May 27 08:02 scsi-3600508b1001c801d4521682fac529211 -> ../../sdf

those are the 4x16T drives. 

/sbin/qm set <vm_number> -scsiN /dev/disk/by-id/scsiNNNNNNNNNNNN

is the generic command. You will have to fill in the blanks of <vm_number>, scsiN, and the disk ID. 

-scsiN specifies the interface used and N is just a made up number, a single-digit in my case.

Ultimately:

/sbin/qm set 102 -scsi2 /dev/disk/by-id/scsi-3600508b1001c710b4c7493cf3630fb6f

/sbin/qm set 103 -scsi3 /dev/disk/by-id/scsi-3600508b1001cd17c6f7fea6ce6d097d5

/sbin/qm set 104 -scsi4 /dev/disk/by-id/scsi-3600508b1001cc9fc14dafef1c4174c23

/sbin/qm set 105 -scsi5 /dev/disk/by-id/scsi-3600508b1001c801d4521682fac529211

This attaches one drive to each of the four VMs (102-105). They will show up as /dev/sdb.

For each VM you will do standard things:

sudo mkfs -t ext4 /dev/sdb

sudo mkdir /mnt/data

sudo chmod a+rwx /mnt/data

sudo mount -t ext4 /dev/sdb /mnt/data

df -k         

will verify that all is good:

and finally edit /etc/fstab for a permanent mount:

/dev/sdb    /mnt/data    ext4    defaults    0    0

sudo mount -a

sudo systemctl daemon-reload

At least as of PM 9.2 the PM GUI doesn't help you do this. It's not hard, per se, but there's clearly a good bit of mechanics.

End result: I have four VMs each with local disk of 60GB and each one has a locally mounted 16TB disk for data. Because those disks are local this is as fast as its going to get.

(if your VMs will run Windows, instead of -scsiN you will use -virtioN instead of -scsiN, and you're going to need a special software driver acquired separately from ProxMox. I wasn't doing this)

-----------------------------------------------

After getting all that setup done, Seaweed volumes running in VMs didn't want to talk to Master, and some further reading led me to the conclusion that VMs are a bad idea here.

So I dropped this whole idea. It turns out you can run more than one Volume Manager along with the Master on the host OS. I reinstalled Ubuntu at the top, and mounted the 16T disks directly. Each one will go with a Volume Mgr, as I was doing in the VMs, but here with better performance, less overhead, and probably correctly working comms. One point in the Seaweed docs it says 8TB maximum space for a Volume, so I may be violating that already. If so, I'll back down to some 3TB spares I have.

Sure enough, right there it says 8000 GB. The disk is 16, so half is wasted? Should I partition that disk into two? This would not have looked good in VMs, there would be twice as many.

And, looking at the Master's web interface:

You can see I fired up 4 Volume servers. I really need to deal with that 8TB limit. And put better CPUs in there; it has E5-2620 Hex-cores, which seems ok for just 4 volume servers, but not enough for 8. Pretty sure I have some 8-core 2640 or something in a box. Maybe I'll spend the $ for some 2698 V3/4s...

FWIW, my test machine has 8 drive slots, 4 for SSDs and 4 for 3.5" HDD. So it's not like I can just put more more smaller drives, 8T or less, and have more volume managers. Yes, I could partition a 16T into two 8T drives, but they aren't operating in parallel on a single drive. 

My impression is that the reason for the 8T limit is because SW is focused on smaller files, and the qty could get crazy with larger Volumes.

On top of that there's some other weirdness going on. Ubuntu HATES having seaweed defined as a "service". That is a disaster, breaks the boot, drops you into recovery mode, giving enough power to turn it off as a service, and then reboot. I don't know what is going on, yet. I can start it just fine from a shell login, seems to run fine, incl the Volume Mgrs, but not as a service enabled at boot time. That can't be right. I couldn't get it to behave by using crontab either. Later: I think I had it autostarting, via systemctl.

Later: It may be that I am doing that Volume Server wrong, and that you want one per machine, it each one handles multiple disks. That has appeared to be the case as I have done further reading. Seaweed is TERRIBLE about documentation with the severe lack of online help, or videos.

But what I think I know now: You want one (or more?) Masters on separate machines, one Volume on each participating machine, one Admin per Master, one Filer (per machine? per Volume?), maybe an S3 if you need that; apparently starting S3 also starts a Filer. And then the WebDAV and other thing, if you ned those. 

When you start Volume Server, you can specify "folders": "-dir=folder,folder,folder" and each folder should be a separate mounted disk, I think, again the 8T limit so I think drives no bigger than that.

Component startup order seems important, not sure why:

Master

Volume

Filer

S3

Admin

Shell

It appears that S3 behavior requires a Filer already running; it seems to hang without one; documentation implies that S3 will start a Filer if there isn't one, but that didn't seem to be happening. Admin certainly requires a Master. Shell requires a Master.

Later later: this new arrangement seems to be working OK now. I have Most of the services running on the same machine. That machine has a public-facing IP. Admin runs on a different machine that does NOT have a public-facing IP, so the Admin GUI is only available on my LAN.

----------------------------

Rustfs.

Similar to Seaweed. There's a single executable, same as SW. Where SW is focused on smaller files, RustFS is not. Rustfs is newer, and therefore less stable. There are some good comparisons on YouTube.

It looks similarly easy to start up, although less traditionally organized. One unique feature: it wants to use XFS as the underlying file system. I have no experience with XFS. You can run in 3 modes:

1) one machine one volume

2) one machine multiple volumes

3) many machines many volumes

For my first test I have a couple of under-powered DL360 Gen 6/7 machines that have plenty of RAM but not much disk. They are both configured with a RAID-1 pair of 10K SAS disks to boot from, and the rest of the disks are a RAID-50 group. Ultimately that is then two machines and two volumes. There's no "Master Node" like in Seaweed.

Data Center: configuring NextCloud for HTTPS

 You do want your WAN-facing NextCloud to be using HTTPS, the TLS-based web-service.

NC uses Apache by default, altho you can set it to use NGINX. I have not switched, just going with the NC default install. It is not quite a normal Apache.

First thing you need are some server Certificates. You can create self-signed ones, but they aren't as friendly as web-browsers want.

Lets Encrypt works ok. This article will describe doing that. The only real flaw about LE Certs is that they are only 90 days.

THIS IS UNFINISHED

Apparently you put the certificate files into:

/var/snap/nextcloud/current/certs/custom/

which you will have to create. And then run this:

sudo nextcloud.enable-https custom -s cert.pem privkey.pem chain.pem

with whatever relevant name changes are required.

We will use CERTBOT to do the install after we create them.

sudo apt update

sudo apt upgrade

sudo apt remove certbot

sudo snap install core; sudo snap refresh core

sudo snap install --classic certbot

which certbot

finally:

sudo certbot --nginx

sudo certbot --apache

Data Center: Working with NextCloud

 I won't claim this writing is in any way exhaustive. It was exhausting...

The problem begins like this:

I want to have a "cloud file service" that I can use, and others can use, and I can offer better pricing.

So overall it looks like NextCloud is the right tool. It really has a lot of features I want. Maybe the only thing missing is an S3 interface to the users.

But I'm telling you, this isn't nearly as easy to set up as I was expecting it to be. This little chronicle will describe most of what I went through, and where I ended up. Which is to say, seriously incomplete.

You can get nextcloud installed as part of the ubuntu installer. That is the easiest way to go. Trying to figure it out after the OS install was too complicated. Do the easy thing.

(otherwise apparently it is "sudo snap install nextcloud" which looks really easy but I haven't tried it; NC wants a couple of other tools as well, like a database and apache/nginx)

First info: I was installing on an HP DL380 G9, with 80GB RAM, and a chunk of RAID space. I don't remember where I started with that, but here this week it was approx 18TB, and a small RAID volume of 150GB for OS install on 10K SAS drives. Sounds easy enough, right? Two RAID volumes, one for OS, one for cloud data.

So I did the simple install, fixed up the IP addresses, fired up NextCloud, created the admin account, and began to push some files over. I tried to copy all the music library from my desktop machine, to this new "cloud" filespace, 130 GB of data. And it ran out of space pretty quick. So I wondered what was going on, and the answer was that the big RAID volume wasn't in use. 

So I tried to figure out how to make it be in use, and the NextCloud answer is that that is not possible after the initial setup. I think that is where I dropped the ball a year ago. Had other things to worry.

This week I needed to come back, but I'd forgotten about that machine being in that awkward unfinished state. 

Had reinstalled Ubuntu/NC some months back, it was sitting as-yet-unconfigured, so I did the initial stuff, and noticed that I could specify a data folder; don't remember seeing that previously. This is important. Tried to copy the music files up again, rand out of room at about 50GB. WTF? This machine has a huge RAID, what's the deal?

Well, there's that *little* RAID volume, and that's where NC was putting data: because I didn't tell it not to. And that RAID volume was 150GB total, and it has the OS on it, and whatever the hell else the installed does. AAARRRGGGHHH! Of course it bombed out at 50GB.

Well, I have more drives now, so I pulled those two out, and put a pair of 2T drives in (these two are in the back). Rebooted, reconfigured the RAID to a single group, and--whoops! two other drives are not the matching size, gotta swap them too. A quick moment on that and now there are 14 2T drives in a RAID 60 group, and I can do a reinstall with a more consistent size. The HP RAID controller really wants all the drives in a group to be the same, and I had had a pair of 146GB drives in the back as their own group. (One thing you could do here is use a pair of SSDs for the OS, 250GB probably being the right size.)

Full OS reinstall with NC, fixed the static IPs again, retry with the copy the music files attempt.

Fails at 80GB. WTF! Well, it turns out, somewhat the same deal. The Ubu installer has made some assumptions I didn't know about regarding how it created file partitions. I do not know what it was thinking here, but linux is an annoyingly complex thing at this level. My unix understanding began 30 years ago but then there's a huge time-gap where I didn't touch it. So now I can go look at what happened, but i don't understand some things. But again Ubuntu has done some partitioning of this one huge RAID volume into pieces it likes that I don't really know the entire purpose of.

So I hunted around to try to understand a bunch of things. Various linux commands would tell me various things. 

mount would tell me that sda1 and sda2 are mounted, but sda3 is not. sda3 is the big remainder space. I don't understand how this is possible, as there's just the one RAID volume, but ok, I know how to format and mount partitions. But no, it's already mounted, and I can't see how or where.

Eventually I see enough indicators to tell me it has gotten some flavor of "lvm" partition that isn't very big (100GB), and approx 15TB is inaccessible. This is just not what I want.

So I went online for some more info, read a little about LVM, watched a couple videos, ok, yeah, this is interesting, I should learn about this, sounds like LVM will do interesting things I want to do, but this feels like not the time. I really do want to do some of the expand/add/replace routine, but I need to think about how and what. 

So back to the RAID drawing board. I am doing a new pair of RAID partitions, where the two drives in the back are going to be a RAID 1 group for the OS, and the other 12 are a RAID 60 again, that will be an entirely separate mount that I will use for NC from the very beginning.

So that is where I am. OS being installed now. Infernally slow, it took 2 hours earlier. I think the RAID controller is redoing the RAID parity initialization, which takes a day or two at this size.

What I'm hoping to end up with is that the 2T RAID 1 group has all the OS goings on and that the other 16T RAID group isn't even mounted, so that I can do that and tell NC to use that mount as data space. Will be finding out tomorrow how well that works.

(Next after that is trying out an S3 server tool or two; pretty sure I need to be able to understand and do this. It doesn't *LOOK* all that complicated, but that has to be a whole nother machine so it doesn't interfere with the NC instance(s). For the moment, I need the behavior, without needing the more serious content management like replication.)

And of course LVM is a whole bigger topic. I'd LIKE for there to be a gui tool for this somehow, where I only need to "draw a picture" of what I want to do. Of course I'd like that for network config too.

And now I've just realized that the other LAN-only machines I set up NC on are also improperly configured. Argh. Yep, here's a picture of some of it on one machine:

You can see right there that although sda3 is the big partition, most of it is not mounted at all.  So do I need to do this over again, or can I just expand that thing to fill all the unused space? Or do I make another partition that is lvm like "ubuntu-vg-ubuntu-lv" and join them? I guess we're going to find out; this machine is unused at the moment so it's easy enough to experiment, and it's LAN-only so I don't care about having to re-install the OS. I need to do some more reading.

This is a little big bogus right off the bat:

You can see that the existing single volume-group is 100GB and that freespace is 22TB. WTAF is THAT about?

Now I wonder how many other machines I have badly configured in this same way? And why is this the default?

I found this web-page helpful here:

https://packetpushers.net/blog/ubuntu-extend-your-default-lvm-space/

This is the before picture on the second machine:

This is the command sequence:

This is the after picture:

NextCloud didn't like being told a specific folder to work with. No idea what was going on there, so I am back to the re-install. I thought about trying to tell it up front how to create partitions, but that did the wrong thing.

This is the starting point on disks. Looks good, yes?

This appears to be going to set a LVM group and LV to 14.5T, which is the full disk. Problem: there are two LVM groups, and you can only modify the size of one of them, and that one turns out to not be mounted anywhere, and I'm not yet sure how to achieve that. (This machine is currently set to two RAID volumes, one in the back, RAID 1, 2x2TB). The USB entry is the thumb-drive I am installing from.

So I'm back to a re-install where I let it run all the defaults, and will patch it later. We'll see how that goes, given that I have two RAID volumes; I may do this yet again with the RAID changed to a single volume.

Later: just did the singe RAID volume. Also, I set the lvm partition to be the entire disk, rather than just the 100 GB that it otherwise defaults to. Waiting for the install to complete as I am typing this.

Looks like the right thing now. Going to fire up NextCloud now and try to push all the music files up there again.

So the latest install now has a single LVM partition, boosted to include the entirety of free space. I have just uploaded 120 GB of music, which means it is configured correctly finally. I am going to need to repeat this on another machine, just to be sure I can.

Data Center--Set Up ProxMox Cluster from scratch

Set Up ProxMox Cluster from scratch

First we need to create the remote server that will be large filespace that we will need to mount more than once.

Install Ubuntu on a machine with a lot of space. Make a folder that is going to hold ISOs.

I.e., 

During boot time, make a disk group that is the boot RAID pair, and a second group that is RAID 5 or 6, whichever does the stripe/parity thing. 

Install UBU on the RAID group that is just the pair.

Once that is done, and fully updated, mount the larger RAID disk LUN as /mnt/storage

sudo mkfs -t ext4 /dev/sdX

Verify this by doing a mount.

Sudo mount -t ext4 /dev/sdX1 /mnt/storage

Diddle as needed to get a successful mount.

Create a folder to hold the ISOs.

sudo mkdir /mnt/storage/ProxMoxISO

Find the ISOs and 

Edit /etc/fstab to do the same thing on a permanent basis

/dev/sdX1 /mnt/storage default 0 1

Install PM 8.3+ on one regular 1U server. 

Create a cluster. This machine will be in it.

Now you want to add a separate server to hold things like the ISOs. Create a folder for this and put at least one ISO in it. 

ALT: have one machine on the same physical network that will host IVENTOY PXE BOOT SERVER.

This will need the PROXMOX ISO as well as any Ubuntu or other ISOs.

Can put IVentoy into a VM, which seems to work ok for separate machines. 

VM ISO storage folder is /vat/lib/vz/template/iso

Data Center file access for VMs

So a next in line problem to work is how to have a VM have access to a file-space of data that is larger than its own disk image.

First some background:

Virtual Machines (VMs) are created with a fixed amount of "disk space". This amount is whatever number you give it when you create the VM. In this era of giant disks, no reason to be cheap on this; I will discuss with the customer/user how much they want, but I don't expect to give anyone more than 1TB.

Servers with four disk drive slots can hold ~100TB of space. They can have max 20-24 VMs running without having trouble about CPU core utilization (where each VM is using one core; fewer VMs if they use more than one core). So in theory each VM could have ~5TB of its own space. Those are big VMs at that point.

If a user is needing more than that, they should be using a separate file-share hosted on another machine whose purpose is hosting and sharing files. This article is about that setup.

There are several ways to do this. I have not investigated them all. Several are better integrated into ProxMox (CEPH and ZFS for example). 

I did, ~2 years ago, have a Windows Server 2022 DC Edition in operation. That particular group of five machines had really weak passwords and got hacked after I put it online. I wiped those several machines and started over, but I didn't bring back the Windows share(s) I had created...that was a "lab cluster" so it didn't matter too much.

This time, however, I want to do this better, with greater controls. So Samba it is.

Step one is install Ubuntu as the host OS. Standard approaches apply, either a USB or a PXE server. I'm trying to only use PXE at work, with a USB at home so I don't have to have another server running at home.

---

Turns out Samba on linux is harder to set up and configure than it ought to be. What an annoyance. Samba would be fine for other situations, not this one, where I need the size-limit quotas.

Seems likely to be easier with Windows Server which has quotas built in. I never set them up last time, didn't care at that moment. Shares are advertised via CIFS.

Have to wonder how an iscsi box would do that as well. No, apparently not intrinsically. 

Linux Servers wanting to use a Windows CIFS Share need to install smbclient and cifs-utils. You will want to mount CIFS shares via fstab at least some of the time. Pretty sure I did that before.

---

Installing Windows

Weirdly, it turned out I had 8 4T drives and one 3T drive in the RAID, so I pulled the 3T out, recreated the RAID, and started the Windows install. It then proceeded to bitch about not being able to install onto that logical drive, wrong partition type, blah blah something. Did some online reading that didn't exactly give the answer about what to do. (That 3T in the previous RAID was doing a negative thing for me, reducing the max size on the user side.)

The REAL answer: Windows wants to install to an MBR partition, which max size 2T. I swapped out drives so that I could create a 2x2T RAID 1 Mirrored group, and one 7x4T RAID 5 group. The machine was damaged in transit before I received it, so I can only put 9 total drives into it, thus 2 + 7. That's good for now.

Windows then cleanly installs, so the problem is not these other weird things I read about, it's the drive capacity/size. Install Windows to a 2T bootable, and let the other one, which is bigger, be the CIFS share.

Windows Server is a pretty easy install. You have to run Update after that, but that's fine. You should automate that anyway.

---

I'll need to be careful about the firewall aspects of all this, in the gateway as well as individual machines. I mentioned getting hacked in 2024. I should have been more careful about controlling the gateway to block things unwanted. As well as forcing better passwords, maybe even 2FA.

Data Center: Using NextCloud

It is STAGGERING how many web-pages purport to tell you where the NextCloud files are and just don't.

If you install Ubuntu in mostly default mode, at one point there's an option to install some 3rd-party tools along the way, and one of the choices is NextCloud.

https://georgenswebsite.com/operating-systems/ubuntu-server.jpg

You can see NextCloud is the second choice. It installs into some folder, you aren't told what it is. Mostly you don't care.

Answer: /var/snap/nextcloud/current/

Why I went to look for this: I'm getting an error I don't understand, it says I need to look at the log files. Which I can't find. 

/var/snap/nextcloud/current/ has a folder called "logs" but that is empty. I did find an indication that maybe that just holds mysql errors.

Some online reading suggest the log files are in the "data" directory, but I can't find that either.

Apparently NC uses an Apache install as its server/interface. Normally you would find that in /var/www/ but no.

If you did a manual installation:

https://docs.nextcloud.com/server/stable/admin_manual/installation/installation_wizard.html

that says /var/www/ but the ubuntu/snap installation does something else...you get a bunch of defaults chosen behind the scenes, which are difficult to change later.

One thing I would like to do is occasionally add disk capacity, but that has looked difficult. Setting NC to use non-default file-space looks hard, at best.

Best I can tell is that the data folder is inside the Apache folder, and the logs I want are there. But as I write this I don't know where Apache is either. And "data" is def not in /var/snap/nextcloud/

The intent here appears to be that your NextCloud host machine is doing NC and *nothing else* and you don't want to mess with it.

So when you do the initial NC setup, and are giving the admin account name, you get this:

So the data will be in /var/snap/nextcloud/common/nextcloud/data/.

Logs are in /var/snap/nextcloud/current/logs/ -- You will have to sudo to look at this, and maybe chmod to "logs" in order to get into the folder to look at the files. The window with the error message was this:

which isn't especially helpful. Turns out it means the server has to name itself as a "trusted machine". You have to go edit 

/var/snap/nextcloud/current/nextcloud/config/config.php

to fix this, there's an entry for "trusted_domains" that needs IPs added. You probably want to be VERY specific about this.

What I specifically had to do here was add a "trusted-domain" that is my WAN IP address. This is not about users' local-at-their-end IP addresses, which is what I was expecting. It OUGHT to be a user's personal WAN IP but it isn't.

Check it first with:

sudo nextcloud.occ config:system:get trusted_domains

I got some IP numbers, what I had entered.

If you need to add one or more, do this:

sudo nextcloud.occ config:system:set trusted_domains 2 --value=exampledomain.com

where exampledomain.com could be an IP address. You can have multiple, the "2" is just a sequence number. I tried changing this, reboot, etc. Didn't help, so it was simpler to just reinstall from scratch than to try any harder to figure it out.

What my problem had been: I changed the underlying IP address for the machine. NC has some security controls related to this, so that's harder than it ought to be. (I am also using ProxMox, that has some complicated IP aspects.)

You database info is this:

If you want to do external access into the database (mysql in this case) you should show and save that password, it's a random string. An inch farther down is the "install" button. I clicked it and it is taking a good while to finish up, a couple of minutes in the end.

This is all almost absurdly complicated. Don't be wanting to fiddle with it more than once, that's for sure.

Once that "Install" is done, you now have a data folder, and can go, on a command line, to that folder to verify that a Admin folder exists under the name you just gave.

I went ahead and installed "Recommended Apps" because I expect customers to want to use some of them.

I am hoping that "Talk" is like Zoom, but it might be more like Slack. Apparently it is.

https://nextcloud.com/talk/

I have read that you can change which folder holds all the "data space" for NC, away from the default. It too sounds difficult, where in fact it should be made easy to allow me to add space, for down the line when I can afford bigger disk drives.

The way to begin with this is to get a standard HP DL380 15xLFF 3.5" drive spaces. They aren't expensive. Put the full 15 of 4TB drives in there, config that at boot time as one large RAID 50 (or 60 if you have had disk troubles). Then install ubuntu server (using PXE boot installer if you followed that other blog), check true for install NextCloud. All the default things will behave the right way, give it the IP you want, all is good.

Now you are at the startup screen to make the admin account, and can begin creating accounts, etc.