Beiträge von MarcS

I have the latest docker update (docker-ce 5:24.0.7-1~debian.11~bullseye) ready for installation.

Shall I go ahead?

I have not done anything. The system has been fixed for at least 1 month. All I did was keeping it up to date with updates.

Sorry - I dont know how to reproduce it as the above cron job seems to be an OMV system job which I cannot even see.

Since a few days I am getting this error message every hour. I have not changed anything to my system in several weeks.

Has anyone seen this? Seems to be related to BTRFS cleanup tasks.

Any ideas how to fix this?

/etc/cron.hourly/openmediavault-cleanup_sf_snapshots:
ERROR: Could not destroy subvolume/snapshot: Directory not empty
Traceback (most recent call last):
  File "/sbin/omv-sfsnapadm", line 244, in <module>
    sys.exit(main())
  File "/sbin/omv-sfsnapadm", line 240, in main
    cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 73, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/sbin/omv-sfsnapadm", line 235, in cleanup_cmd
    delete_snapshot(snapshot, simulate)
  File "/sbin/omv-sfsnapadm", line 107, in delete_snapshot
    openmediavault.procutils.check_call(
  File "/usr/lib/python3/dist-packages/openmediavault/procutils.py", line 58, in check_call
    return subprocess.check_call(*popenargs, **kwargs)
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['btrfs', 'subvolume', 'delete', '/srv/dev-disk-by-uuid-786fbfe4-2782-4b41-b28a-9ec8130edb8d/.snapshots/OMVmoving@hourly_20231029T010001']' returned non-zero exit status 1.

Zitat von bishoptf

Update: Did some searching and found a post with a similar issue, required me to go into NFS settings and reselect the versions etc...finally applied without issue and NFS service is now running, whew....:)

thank you so much for sharing. Hd the same error and your fix worked. This post probably saved me hours of work.!!

got it thanks

Zitat von macom

for merged filesystems yes, but not for the filesystems that are being merged AFAIK

Ah. I see. So I can use fstab for changes.

thanks

Thanks but the method described here seems to be based on amending fstab,

...Save the file with CTRL+X, run: omv-salt deploy run fstab

You should be able to see the new options at /etc/fstab

while I believe fstab is no longer used for mounting.

Am I right?

I'd am running btrfs on a SSD RAID and would like to mount it with options such as -o ssd and -o autodefrag

How can I define customised mount options in OMV?

Its a common SAS controller based on the LSI 2308 chip which has widely been reported as supporting 4Kn drives.

The controller has nothing to setup and the other SAS drives work well. The 4Kn drive shows up there in the list without any issues, even shows the right size 3.7TB so the controller knows about the 4096 sector size. Other SAS controllers I tried did not show the correct disk size as they did not support 4K sectors.

I will check the firmware. Maybe i need to tweak that.

thanks

Kernel 6.1.0-0.deb11.7-amd64

Here it seems to see 3 disks

root@T110:~# sudo dmesg | grep -A3 'Attached SCSI'
[    1.745168] sd 4:0:0:0: [sdc] Attached SCSI disk
[    1.779150] sd 1:0:0:0: [sda] Attached SCSI disk
[    1.780872] usb 1-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00
[    1.780880] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.781469] hub 1-1:1.0: USB hub found
--
[    1.803448] sd 2:0:0:0: [sdb] Attached SCSI disk
[    2.084472] usb 2-1.5: new low-speed USB device number 3 using ehci-pci
[    2.199252] usb 2-1.5: New USB device found, idVendor=1c4f, idProduct=0002, bcdDevice= 3.30
[    2.199260] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
--
[   10.535921] sd 0:0:2:0: [sdf] Attached SCSI disk
[   10.551374]  sdd: sdd1
[   10.551464] sd 0:0:0:0: [sdd] Attached SCSI disk
[   10.558765]  sde: sde1
[   10.558827] sd 0:0:1:0: [sde] Attached SCSI disk
[   10.780442] raid6: sse2x4   gen() 16702 MB/s
[   10.848441] raid6: sse2x2   gen() 17768 MB/s
[   10.916440] raid6: sse2x1   gen() 14077 MB/s

>> my parted --list output:

# SATA drive (not scsi)

Model: ATA TOSHIBA DT01ACA0 (scsi)

Disk /dev/sda: 500GB

Sector size (logical/physical): 512B/4096B

Partition Table: loop

Disk Flags:

Number Start End Size File system Flags

1 0.00B 500GB 500GB btrfs

# SATA drive (not scsi)

Model: ATA ST3000VN007-2E41 (scsi)

Disk /dev/sdb: 3001GB

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 17.4kB 3001GB 3001GB ntfs msftdata

# SATA SSD

Model: ATA Corsair Force GT (scsi)

Disk /dev/sdc: 60.0GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 59.0GB 59.0GB primary ext4 boot

2 59.0GB 60.0GB 1022MB extended

5 59.0GB 60.0GB 1022MB logical linux-swap(v1)

# 'normal SAS drive, non 4Kn

Model: SEAGATE ST330006CLAR3000 (scsi)

Disk /dev/sdd: 3001GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 1049kB 3001GB 3001GB ext4

# 'normal SAS drive, non 4Kn

Model: SEAGATE ST33000650SS (scsi)

Disk /dev/sde: 3001GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 1049kB 3001GB 3001GB ext4

I have a problem with SAS 4kn (native) harddrives, connected to my server via a SAS controller.

The controller can see the HD and it reports correct size 3.7 TB but after booting, in OMV/Debian the drive does not show up at all.

The drives are 4TB Seagate drives, type  ST4000NM014

The SAS controller is a HP (725904-001) 9217-4i4e-HP - FH PCIe-x8 RAID Controller running in IT-mode (HBA).

The controller also has 2 'normal' SAS drives attached and they work well under OMV.

Is there anything I need to install to make 4Kn drives work?

i have the same problem...

Zitat von ryecoaaron

sounds like a docker upgrade broke your docker install.

I think you are right. Appologies, it just looked to me like the Compose Plugin was causing the problems because it had a 20 page error message and I assumed that all the new Compose features caused docker to break. I don't know what exactly is the problem and my docker remains faulty, but it seems that some new docker versions don't run on my RPI. Maybe its time that I throw it overboard and buy one of those monster 1U servers with Xeon CPU and 12xHDDs :))

Zitat von ryecoaaron

I get it you are mad but out of all the times I have helped you on this forum, for you to act like this to me and my work, it is very disappointing.

Sorry - I am not sure what you mean. I posted my server issues which came with the latest upgrades. I used to have super stable servers, now all is gone. The error message comes up in the OMV Compose plugin. So thats all I can go by.

Zitat von ryecoaaron

. If you didn't install the compose plugin, portainer would be running if docker was ok.

I agree - I do not want the compose plugin as I run Portainer. And I would have never installed it but since a few upgrades back, OMV requires us to install the Compose in order to run Docker. Docker used to be an option under OMV-Extras and had its own tab for path settings. Sadly this is gone due to all this innovation

Zitat von Soma

If yes, you found your problem. Neither docker root nor container configs should be on a merged FS.

EVER.

That is not the issue. Docker worked perfectly fine on mergerfs (for last 4 years). I have also confirmed with the author of mergerfs that there is no issue with docker.

Zitat von chente

No one is stopping you from continuing to use Portainer. Install it and go.

I would but it does not work. After the upgrade docker doesnt work and Portainer is just a docker container. Since docker no work -> all containers no work -> portainer no work

Zitat von ryecoaaron

Continuous improvement

Thats great but then it would be good to do some testing prior to releasing "improvements". We used to have a stable OMV and now its not and unfortunately there is no way to roll back.

As a workaround for others who might encounter this issue:

Downgrade docker:

sudo apt install docker-ce-cli=5:20.10.23~3-0~debian-bullseye 
sudo apt install docker-ce=5:20.10.23~3-0~debian-bullseye 
sudo service docker restart

After that, OMV allows to save the settings without error.

You might need to spend a few hours restoring your containers and not all of them will work 100% (e.g. Nginx and Dozzle throw errors). Of course its no solution but at least containers are up.

Zitat von ryecoaaron

Are you still using Windows XP???

Well, Compose reminds me a lot of Windows XP. Have you tried Portainer? Its much more user friendly, quicker and stable....