Replication issues after third successful replication

Troubleshooting
1

Hello everyone, it’s me again.

I have run into an issue where when I start a replication of a share from one rockstor appliance to another it will fail after three successful replications. Failure on the receiving machine is something like “Failure to promote oldest snapshot to share”.

I have searched through the forum and found some threads and github issues touching this problem and some solutions that where proposed there.
I’m tagging @phillxnet directly because I can reproduce this issue with at least one share.

So far I tried disabling quotas on the receiving pool, which did not work.
I tried making the snapshots on the receiving machine RW which also did not work.
I did not modify any of the existing python files und /opt/rockstor/src/rockstor.

If error logs or logs in general are requested I will try to provide them as fast as possible. I didn’t want to clutter the starting post with unnecessary text.

What may be of notice is that the receiving machine is completely LUKS encrypted.

Addendum: I also noticed whenever I try to delete a share I get an error with “device is busy” but the share is still correctly deleted. I believe I read somewhere this is also related to quotas.

Addendum 2: I also noticed that with Replication my transfer speed seems to be capped at around 1GBit for networking although i have 10GBit available. A test with rsync tells me I’m at around 2GBit (which is what I would expect for HDDs R/W speed)

2 Likes
2

@Reynevan can you also post the Rockstor version you’re on as well as the openSUSE flavor you’re running on? Mostly to ensure you have the latest replication fix in.
Can you also post the latest error messages from the Rockstor log that is related to replication?

3 Likes
3

Sorry for not getting back to this earlier but I was away over the weekend, it was very warm and I had some logging issues on my receiving machine.

So I decided to do a new replication to reproduce the issue:

  • a small Share with a few MB of content
  • sent every 5 minutes

Sender

  • runs rockstor 5.1.0-0 on openSUSE Leap 15.6 (which may be the root-cause?)
[10/Aug/2026 12:00:03] INFO [smart_manager.replication.sender:341] Id: 03d502e0-045e-05a2-3d06-950700080009-13. Sending full replica: /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_13_replication_1
[10/Aug/2026 12:05:15] INFO [fs.btrfs:1598] Quota data changed, rescan scheduled
--- WARNING: auto quota rescan overlap 
(ERROR: quota rescan failed: Operation now in progress)
[10/Aug/2026 12:05:15] INFO [smart_manager.replication.sender:335] Id: 03d502e0-045e-05a2-3d06-950700080009-13. Sending incremental replica between /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_13_replication_1 -- /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_13_replication_28
[10/Aug/2026 12:10:02] INFO [smart_manager.replication.sender:335] Id: 03d502e0-045e-05a2-3d06-950700080009-13. Sending incremental replica between /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_13_replication_28 -- /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_13_replication_29
[10/Aug/2026 12:15:06] INFO [fs.btrfs:1598] Quota data changed, rescan scheduled
--- WARNING: auto quota rescan overlap 
(ERROR: quota rescan failed: Operation now in progress)
[10/Aug/2026 12:15:06] ERROR [storageadmin.util:45] Exception: duplicate key value violates unique constraint "storageadmin_snapshot_share_id_name_10142bd3_uniq"
DETAIL:  Key (share_id, name)=(44, docker_bazarr_config_13_replication_30) already exists.
Traceback (most recent call last):
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
psycopg.errors.UniqueViolation: duplicate key value violates unique constraint "storageadmin_snapshot_share_id_name_10142bd3_uniq"
DETAIL:  Key (share_id, name)=(44, docker_bazarr_config_13_replication_30) already exists.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py", line 40, in _handle_exception
    yield
  File "/opt/rockstor/src/rockstor/storageadmin/views/snapshot.py", line 176, in post
    ret = self._create(
          ^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/contextlib.py", line 81, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/storageadmin/views/snapshot.py", line 154, in _create
    s.save()
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py", line 814, in save
    self.save_base(
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py", line 877, in save_base
    updated = self._save_table(
              ^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py", line 1020, in _save_table
    results = self._do_insert(
              ^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py", line 1061, in _do_insert
    return manager._insert(
           ^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/manager.py", line 87, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/query.py", line 1805, in _insert
    return query.get_compiler(using=using).execute_sql(returning_fields)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1822, in execute_sql
    cursor.execute(sql, params)
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py", line 67, in execute
    return self._execute_with_wrappers(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py", line 80, in _execute_with_wrappers
    return executor(sql, params, many, context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py", line 84, in _execute
    with self.db.wrap_database_errors:
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/.venv/lib/python3.11/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
django.db.utils.IntegrityError: duplicate key value violates unique constraint "storageadmin_snapshot_share_id_name_10142bd3_uniq"
DETAIL:  Key (share_id, name)=(44, docker_bazarr_config_13_replication_30) already exists.
[10/Aug/2026 12:15:06] ERROR [smart_manager.replication.sender:79] Id: 03d502e0-045e-05a2-3d06-950700080009-13. b'Failed to create snapshot: docker_bazarr_config_13_replication_30. Aborting.'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/44/snapshots/docker_bazarr_config_13_replication_30
[10/Aug/2026 12:20:02] ERROR [storageadmin.util:45] Exception: Snapshot (docker_bazarr_config_13_replication_30) already exists for the share (docker_bazarr_config).
NoneType: None
[10/Aug/2026 12:20:02] ERROR [smart_manager.replication.sender:79] Id: 03d502e0-045e-05a2-3d06-950700080009-13. b'Failed to create snapshot: docker_bazarr_config_13_replication_30. Aborting.'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/44/snapshots/docker_bazarr_config_13_replication_30

Receiver

  • runs rockstor 5.5.5-0 on openSUSE Leap 16.0
[10/Aug/2026 12:05:08] ERROR [smart_manager.replication.receiver:415] Id: b'03d502e0-045e-05a2-3d06-950700080009-13'. No response received from the broker. remaining tries: 9
[10/Aug/2026 12:05:14] ERROR [smart_manager.replication.receiver:415] Id: b'03d502e0-045e-05a2-3d06-950700080009-13'. No response received from the broker. remaining tries: 8
[10/Aug/2026 12:15:02] ERROR [smart_manager.replication.receiver:100] b'Failed to promote the oldest Snapshot to Share.'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/38/snapshots/docker_bazarr_config_13_replication_1/repclone
[10/Aug/2026 12:20:02] ERROR [smart_manager.replication.receiver:100] b'Failed to promote the oldest Snapshot to Share.'. Exception: Share matching query does not exist.
1 Like
4

Not sure that the sender’s version is the root cause, however between 5.1 and 5.5.5-0 there were a couple of replication fixes applied, so it could very well be.

Here we have the promotion from snapshot to share on the receiver side. It could be that this is related to the behavior observed earlier (and not resolved yet):

so, if you check further up in the logs on the received side, do you see any quota related messages. And then of course, if you were to manually force a quota scan before starting the replication, will that particular error still occur?

Furthermore, the addition of the force property is also part of the lates Rockstor version, so in theory this should not play a role:

But as you can also see, there is some additional potential to insert some quota rescans down the line.

As for the sender issue, there was at least one fix in that area, related to a missing / in one of the path determinations:

This may or may not be the root cause on the sending side. As you’ve noticed on the forum entries, there has been mixed success on pinning down “the” root cause, as there are sufficient dependencies on other things for replication to go correctly.

If you have the ability to upgrade your sender system, that missing slash could at least be eliminated as the possible root cause. However, I suspect, that sending system is your “production” environment which you might not want to upgrade until the next stable version.

Whatever you do, make sure you have a settings backup, because a fresh install (and restoring from the settings backup) instead of upgrade (especially with an OpenSuse version change) can be more efficient.

2 Likes
5

Thanks for the detailed reply @Hooverdan.

however between 5.1 and 5.5.5-0 there were a couple of replication fixes applied, so it could very well be.

That’s why I thought it may be the 5.1.0-0.

so, if you check further up in the logs on the received side, do you see any quota related messages.

Not as far as I can see, the log is pretty empty. But I can do another test run, maybe something will surface.

And then of course, if you were to manually force a quota scan before starting the replication, will that particular error still occur?

Thats a good point I can try again.
Side-note: I had to delete a broken quota entry a while back from a failed replication so quotas could be re-enabled on the specific pool I was using. I also did a rescan (although without forcing, just btrfs quota rescan /mnt2/my_pool and btrfs quota rescan /mnt2/my_share)

If you have the ability to upgrade your sender system, that missing slash could at least be eliminated as the possible root cause. However, I suspect, that sending system is your “production” environment which you might not want to upgrade until the next stable version.

Yeah the older system is my “production” system which had the sadly unsuccessful update try to rockstor 5.5.5-0/Leap 16.0, where you helped me getting it up and running again :smiley:.

Quick question: Can I just modify/patch the .py-files under /opt/rockstor/src/rockstor/ locally with the contents of the PRs you mentioned in your answer?
I believe I read in one of the threads/posts on here it’s possible, so I would like to try this first.
Because if I can just apply and test those modifications in isolation on my sender production machine, that also may be a way to test things without going through and upgrade/update/restore-process.

1 Like
6

Yes, you can, just be careful to do them in the “right” places :smiley:
Once you’ve done the updates, it’s best to restart Rockstor (or the entire box) then the changes should be considered.

2 Likes
7

So, I was finally able to patch my sender machines files locally with the contents of the linked PRs. I also validated that only those changes had been made.

Sadly the replication still fails, buuuut I get more logs. (somehow - I attribute this to the patched files that seemed to fix some things.)

Sender

[15/Aug/2026 20:10:04] INFO [smart_manager.replication.sender:341] Id: 03d502e0-045e-05a2-3d06-950700080009-14. Sending full replica: /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_14_replication_1
[15/Aug/2026 20:11:02] ERROR [smart_manager.data_collector:1017] Failed to update disk state.. exception: Exception while setting access_token for url(http://127.0.0.1:8000): HTTPConnectionPool(host='127.0.0.1', port=8000): Read timed out. (read timeout=2). content: None
[15/Aug/2026 20:15:04] INFO [smart_manager.replication.sender:335] Id: 03d502e0-045e-05a2-3d06-950700080009-14. Sending incremental replica between /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_14_replication_1 -- /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_14_replication_33
[15/Aug/2026 20:19:07] ERROR [smart_manager.data_collector:1017] Failed to update disk state.. exception: Exception while setting access_token for url(http://127.0.0.1:8000): HTTPConnectionPool(host='127.0.0.1', port=8000): Read timed out. (read timeout=2). content: None
[15/Aug/2026 20:19:09] ERROR [smart_manager.data_collector:1017] Failed to update pool state.. exception: Exception while setting access_token for url(http://127.0.0.1:8000): HTTPConnectionPool(host='127.0.0.1', port=8000): Read timed out. (read timeout=2). content: None
[15/Aug/2026 20:20:04] INFO [smart_manager.replication.sender:335] Id: 03d502e0-045e-05a2-3d06-950700080009-14. Sending incremental replica between /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_14_replication_33 -- /mnt2/docker/.snapshots/docker_bazarr_config/docker_bazarr_config_14_replication_34
[15/Aug/2026 20:20:16] ERROR [smart_manager.data_collector:1017] Failed to update disk state.. exception: Exception while setting access_token for url(http://127.0.0.1:8000): HTTPConnectionPool(host='127.0.0.1', port=8000): Read timed out. (read timeout=2). content: None
[15/Aug/2026 20:20:18] ERROR [smart_manager.data_collector:1017] Failed to update pool state.. exception: Exception while setting access_token for url(http://127.0.0.1:8000): HTTPConnectionPool(host='127.0.0.1', port=8000): Read timed out. (read timeout=2). content: None
[15/Aug/2026 20:25:04] ERROR [smart_manager.replication.sender:79] Id: 03d502e0-045e-05a2-3d06-950700080009-14. b'unexpected reply(b\'receiver-error\') for 03d502e0-045e-05a2-3d06-950700080009-14. extended reply: b"b\'Failed to promote the oldest Snapshot to Share.\'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/40/snapshots/docker_bazarr_config_14_replication_1/repclone". Aborting'. Exception: b'unexpected reply(b\'receiver-error\') for 03d502e0-045e-05a2-3d06-950700080009-14. extended reply: b"b\'Failed to promote the oldest Snapshot to Share.\'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/40/snapshots/docker_bazarr_config_14_replication_1/repclone". Aborting'

I dont know how relevant the errors are but I left them in any way.

Receiver

[15/Aug/2026 20:05:22] ERROR [system.osi:264] non-zero code(1) returned by command: ['/usr/sbin/btrfs', 'qgroup', 'destroy', '0/280', '/mnt2/Docker_Main']. output: [''] error: ['ERROR: unable to destroy quota group: Device or resource busy', '']
[15/Aug/2026 20:05:22] ERROR [storageadmin.views.share:393] Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/280 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/share.py", line 391, in delete
    remove_share(share.pool, share.subvol_name, share.pqgroup, force=force)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1196, in remove_share
    qgroup_destroy(qgroup, root_pool_mnt)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1503, in qgroup_destroy
    return run_command([BTRFS, "qgroup", "destroy", qid, mnt_pt], log=True)
  File "/opt/rockstor/src/rockstor/system/osi.py", line 266, in run_command
    raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/280 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']
[15/Aug/2026 20:05:22] ERROR [storageadmin.util:45] Exception: Failed to delete the share (.snapshots/03d502e0-045e-05a2-3d06-950700080009_docker_bazarr_config/docker_bazarr_config_13_replication_1). Error from the OS: Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/280 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/share.py", line 391, in delete
    remove_share(share.pool, share.subvol_name, share.pqgroup, force=force)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1196, in remove_share
    qgroup_destroy(qgroup, root_pool_mnt)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1503, in qgroup_destroy
    return run_command([BTRFS, "qgroup", "destroy", qid, mnt_pt], log=True)
  File "/opt/rockstor/src/rockstor/system/osi.py", line 266, in run_command
    raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/280 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']

I split the log here because the start is unrelated to the current replication itself. But this was error thrown when I deleted the share created by the old failed replication task to clean things up. Interestingly the share was still deleted correctly.
I also did a btrfs quota rescan of my Pool and Share just to be sure.

At 20.25 the fourth replication was sent over and this is when the replication failed on the receiver.

[15/Aug/2026 20:25:02] INFO [storageadmin.views.snapshot:61] Supplanting share (03d502e0-045e-05a2-3d06-950700080009_docker_bazarr_config) with snapshot (.snapshots/03d502e0-045e-05a2-3d06-950700080009_docker_bazarr_config/docker_bazarr_config_14_replication_1).
[15/Aug/2026 20:25:02] ERROR [system.osi:264] non-zero code(1) returned by command: ['/usr/sbin/btrfs', 'qgroup', 'destroy', '0/283', '/mnt2/Docker_Main']. output: [''] error: ['ERROR: unable to destroy quota group: Device or resource busy', '']
[15/Aug/2026 20:25:02] ERROR [storageadmin.util:45] Exception: Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/283 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/clone_helpers.py", line 92, in create_repclone
    remove_share(share.pool, share.name, PQGROUP_DEFAULT)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1196, in remove_share
    qgroup_destroy(qgroup, root_pool_mnt)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/fs/btrfs.py", line 1503, in qgroup_destroy
    return run_command([BTRFS, "qgroup", "destroy", qid, mnt_pt], log=True)
  File "/opt/rockstor/src/rockstor/system/osi.py", line 266, in run_command
    raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = /usr/sbin/btrfs qgroup destroy 0/283 /mnt2/Docker_Main. rc = 1. stdout = ['']. stderr = ['ERROR: unable to destroy quota group: Device or resource busy', '']
[15/Aug/2026 20:25:02] ERROR [smart_manager.replication.receiver:100] b'Failed to promote the oldest Snapshot to Share.'. Exception: 500 Server Error: Internal Server Error for url: http://127.0.0.1:8000/api/shares/40/snapshots/docker_bazarr_config_14_replication_1/repclone

Edit: The log of the receiver is complete as is, I only split it for convenience.

1 Like
8

@Reynevan Thanks for the detailed and persistent reporting here. Definitely helping to confirm what @Hooverdan suspected I think. And something that has been bugging a few elements of our function in more recent kernels and btrfs: first encountered some time ago only in our Tumbleweed and Slowroll endeavours. However it now affects our Leap 16.0 base due to the newer kernel. It is a big part of why we had TW & SR down as “Development/Advanced-user/Rescue use only”.

In summary I agree with @Hooverdan that the problem is quota related and on the receiver side. We have other straggler and fixed issues such as you patched. But the main one remaining that breaks the snapshot-to-share promotion on receiver is:

I’ve created an issue, and begun working on the necessary updates a few days ago under the following new ‘parent’ issue:

It in-turn references our past (then Tumbleweed only) issues that are also affected. Including an early report akin to yours here already point out by @Hooverdan . Basically, as of Leap 16.0 which we currently only have testing channel support for, we have inherited the newer kernel that has tightened qgroup behaviour and we need to adapt to that. I have successfully modified our ‘ways’ in development code against that issue that addresses all now 3 issues (the earlier replication and later TW Pool delete referenced in my new ‘parent’ issue). And all are down to this upstream behavioural change in quotas and require us to adapt. This adaptation is now understood and I have working in-development code that does not exhibit the indicated reproducers - of which there was non for the replication issue - hence the difficult in addressing that head-on.

Your diligent reports here and @Hooverdan’s probing over time at the heart of what caused this has been key to finally getting our ways updated quota wise. And this very much needed to be done on our current milestone which is where it currently sits:

As there are some low-level behaviour changes in our management of quotas, and how we treat Pool ‘delete’ at a high level also, the in-development changes in-comming are non-trivia - especially as we had some overdue improvements in code style to tend to while there. But it’s looking like a nice set of improvements as well as the indicated issues being resolved.

One question though - what kernel & btrfs version are you running on your sender machine, as you mentioned that was a partially completed Leap 15.6 to 16.0 upgrade. Just lining up the info here ready to get you sorted when the time comes - and if you are also experiencing issues on the sender that where not known to exist before more recent kernel and btrfs updates. The Kernel version is also reported in top-right of Web-UI after the "Uses openSUSE: … Linux: " bit.

uname -a
zypper info btrfsprogs

Hope that helps, and one of use will report here on when the in-development fixes / improvements are finalized.

1 Like
9

Hi @phillxnet, thank you for your reply, that was quite the read :slight_smile:
Your explanation makes a few things more clear to me, I was wondering why some things seemed to work differently on Leap 15.6 vs 16.0.

The kernel/btrfs versions as requested:

rockstorNAS:~ # uname -a
Linux rockstorNAS 6.4.0-150600.23.87-default #1 SMP PREEMPT_DYNAMIC Tue Feb  3 14:58:48 UTC 2026 (0f213a3) x86_64 x86_64 x86_64 GNU/Linux

rockstorNAS:~ # zypper info btrfsprogs

Reading installed packages...

Information for package btrfsprogs:
-----------------------------------
Repository     : Leap_15_6
Name           : btrfsprogs
Version        : 6.5.1-150600.2.4
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 4.2 MiB
Installed      : Yes
Status         : up-to-date
Source package : btrfsprogs-6.5.1-150600.2.4.src
Upstream URL   : https://btrfs.wiki.kernel.org/
Summary        : Utilities for the Btrfs filesystem
Description    : 
    Utilities needed to create and maintain btrfs file systems under Linux.

I’m glad I could aid in narrowing down the root-cause. Maybe one day I can also do more than that and add some fix or code in general with a PR of mine (the backlog seems to contains some issues).

I’m keeping my fingers crossed for the quota management fix/es.

Also thank you again @Hooverdan for going through this whole stuff with me.

I really like how questions and troubleshootings are treated here in the forum :slight_smile:

2 Likes