Unable to mount home folders anymore

[jollino]

I'm opening another thread as this is yet another different issue. It's getting quite frustrating, to be honest.

Situation:
1) F4-423, 4x 8-TB Ironwolf, TRAID (RAID5), with a BRTFS-formatted volume, TOS 6.0.555
2) D4-320, 1x 8-TB Ironwolf, TRAID (just one for now), connected via USB 3.2 to the F4-423, with a BRTFS-formatted volume

Aside from the issue of moving files from the main volume to the external volume and the space hasn't been freed due to old but hidden snapshots (see other post), I am now in a position where a reboot doesn't really set everything up.

After a reboot I see:
- Volume 1: internal volume (HDD1-4), with no shared folders as I use the home folders
- Volume 2: the D4 expansion (sdg), with two shared folders
- Volume 3: another external disk that I use for Time Machine (sde)
- Another 4 GB disk called sdh, which is allegedly formatted as VFAT. It seems to have some kind of TOS bootloader. No idea why it's showing up, it never has before.

However, the main problem is that I'm unable to access shares.
I access the SMB as my user 1, and I can see 1) the home folder, 2) the shared folder on the external expansion, 3) the time machine shared folder, 4) this weird boot disk. Sometimes accessing the external volumes work, sometimes it doesn't. I can't access my home folders, however, which is a big problem as I have most of my stuff on there. My Mac just says "The operation can’t be completed because the original item for "jollino" can’t be found."

journalctl says this:

Code: Select all

Dec 22 17:26:20 Supernova smbd[20540]: pam_unix(samba:account): account jollino has password changed in future
Dec 22 17:26:20 Supernova smbd[20540]: [2024/12/22 17:26:20.952913,  0] ../../source3/param/loadparm.c:3744(load_usershare_shares)
Dec 22 17:26:20 Supernova smbd[20540]:   load_usershare_shares: stat of /var/lib/samba/usershares failed. No such file or directory
Dec 22 17:26:25 Supernova smbd[20540]: [2024/12/22 17:26:25.337719,  0] ../../source3/smbd/service.c:799(make_connection_snum)
Dec 22 17:26:25 Supernova smbd[20540]:   make_connection_snum: canonicalize_connect_path failed for service jollino, path /home/jollino
Dec 22 17:26:25 Supernova smbd[20540]: [2024/12/22 17:26:25.477224,  0] ../../source3/smbd/service.c:799(make_connection_snum)
Dec 22 17:26:25 Supernova smbd[20540]:   make_connection_snum: canonicalize_connect_path failed for service jollino, path /home/jollino

The "enable user homes directory" setting is active, obviously. The data is intact as I can see it in /Volume1/homes through the shell, but for some reason TOS thinks that the homes folder is on Volume3 instead of Volume1. I have no idea why that's even the case but it's probably why it's broken.

The only thing I changed was manually deleting an old snapshot from September (since it doesn't show up anywhere in TOS, but there are many others all the way to late November) to try and solve the issue of the missing free space as I said in the other post (viewtopic.php?t=6787&start=10) even though it didn't help. It doesn't explain why it would make TOS believe that the homes folder is on the wrong volume, however.

This is all VERY frustrating, I'm starting to think I should just return the D4-320 and use the F4-423 alone, since all these problems started with the expansion. It looks like TOS simply isn't designed for keeping USB disks connected all the time.

As always, any suggestions would be most welcome.

[jollino]

After another reboot the weird TOS boot disk did not come back, and while I can now mount the home folder, it's empty because it's coming from Volume3 instead that the actual one on Volume1.

Starting the NAS without anything connected restored the homes on the proper volume, and connecting the D4-320 afterwards shows the disk, but doesn't mount the volume.

At this point my question is: is there any way to ensure that the homes are considered to be on Volume1? I need that to be done if I want to move the data back the home folder, since right now I can't even move the data back from the external disk (assuming it 's mounted as a volume, and assuming I reclaim the space back on Volume1.)

As I said: this is all very, very frustrating.