Thanks for the reply @Flox. Ironically, a few minutes before your post I managed to get my SFTP server back online.
The main problem I had was that the owner and group for my Backup share somehow had its values stored in the Rockstor database set to “root” for both, even though the values on disk were still correctly set to “backup”. Since they were set to “root” in the database, the SFTP service would not use this share.
When I tried to update the owner/group via the Web UI, it would fail after exactly 2 minutes. My system is an old PC circa 2008 with all spinning disks so it takes a relatively long time to run the “chown” command spawned by this change. I tracked the timeout down to the timeout set for gunicorn requests, but even after bumping that up to 30 minutes to allow the chown to complete, this still failed eventually.
Finally, I figured out how to use the psql command to change the right field in the database to convince Rockstor that this share’s owner/group were backup/backup. For reference in case others need to do something similar:
- psql -U rocky storageadmin
- enter password “rocky”
- select * from storageadmin_share
- update storageadmin_share set owner=‘backup’,“group”=‘backup’ where id=9;
Once I made this change, I was able to add the Backup share to the SFTP service and everything is now working as before.
I am not sure exactly how I was able to get the STFP server running in the first place, but looking at my SFTP server logs, it was running prior to my Backup share being re-associated with it, causing clients to fail to find the files they were looking for since the share was not mounted.
The main anomaly now is the disk usage shown for the Backup share, although I see the warning at the top of the Shares screen indicating that quotas are not enforced right now so the size of a share is effectively the size of its pool.
The device of the new disk I added also shows up as “detached-0359b48b77c14907a8d3d8bd88ba1d45” which is wrong. I suspect this is because Rockstor did not account for the disk replacement correctly somehow, since the status of the pool when I look from the command line appears to be as expected (the new disk shows up as /dev/sdg).
Here are a few screenshots and command output:
[root@backup ~]# btrfs fi show /mnt2/Backup_Pool
Label: 'Backup_Pool' uuid: f89b541f-6c7e-4819-a605-124c91f9b428
Total devices 7 FS bytes used 2.51TiB
devid 1 size 3.64TiB used 2.51TiB path /dev/sdg
devid 2 size 1.82TiB used 1.33TiB path /dev/sdf
devid 3 size 931.51GiB used 433.00GiB path /dev/sdj
devid 4 size 465.76GiB used 193.00GiB path /dev/sda
devid 5 size 465.76GiB used 194.00GiB path /dev/sdd
devid 6 size 465.76GiB used 194.00GiB path /dev/sdb
devid 7 size 465.76GiB used 193.00GiB path /dev/sdc
[root@backup ~]# btrfs fi usage /mnt2/Backup_Pool/
Device size: 8.19TiB
Device allocated: 5.02TiB
Device unallocated: 3.17TiB
Device missing: 0.00B
Free (estimated): 1.58TiB (min: 1.58TiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Data,RAID1: Size:2.50TiB, Used:2.50TiB
Metadata,RAID1: Size:6.00GiB, Used:4.24GiB
System,RAID1: Size:32.00MiB, Used:384.00KiB
I believe I am running the latest Rockstor from the Stable channel:
[root@backup log]# yum info rockstor
Loaded plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.it.ubc.ca
* epel: sjc.edge.kernel.org
* extras: mirror.it.ubc.ca
* updates: centos.les.net
Name : rockstor
Arch : x86_64
Version : 3.9.2
Release : 57
Size : 85 M
Repo : installed
Summary : Btrfs Network Attached Storage (NAS) Appliance.
URL : http://rockstor.com/
License : GPL
Description : Software raid, snapshot capable NAS solution with built-in file integrity protection.
: Allows for file sharing between network attached devices.
Anyways, I am back up and running and the remaining issues appear to be mostly cosmetic.
Perhaps when support for replacing disks is added to the Web UI, these issues will be dealt with.
Thanks again for your response and ideas for what to look at.