Posts by Teschbert

Are you having plexmediaserver installed natively? This could currently cause this issue because of an error in the signing process of the sw-package. apt returns error 1.

If its just a data disk: why not easily copy the data from one disk to the other e.g. by using rsync in the terminal?

Its a pretty short command ,,,

And if mergerfs is used its a straightforward process. The old disk only must be replaced in mergerfs config.

Quote from Sulimo

Good to know. Do you have any suggestions on which parameters to change?

I can give you an output of testparm - then you can compare:

[global]
disable netbios = Yes
disable spoolss = Yes
dns proxy = No
load printers = No
log file = /var/log/samba/log.%m
logging = syslog
max log size = 1000
multicast dns register = No
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
printcap name = /dev/null
server string = %h server
smb ports = 445
socket options = TCP_NODELAY IPTOS_LOWDELAY
fruit:aapl = yes
fruit:copyfile = no
fruit:nfs_aces = yes
fruit:locking = none
fruit:encoding = private
fruit:metadata = stream
fruit:resource = xattr
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
readdir_attr:aapl_max_access = no
idmap config * : backend = tdb
create mask = 0644
map archive = No
printing = bsd
use sendfile = Yes

[Timemachine]
force create mode = 0600
force directory mode = 0700
hide special files = Yes
path = /srv/dev-disk-by-uuid-7a81e187-31ff-4fd1-a6d9-2e2baf471464/Timemachine/
read only = No
store dos attributes = No
vfs objects = fruit streams_xattr
fruit:encoding = private
fruit:locking = none
fruit:metadata = stream
fruit:resource = xattr
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = yes

Quote from Sulimo

After updating to MacOS 26.2 the Time Machine backup on OMV share stopped working.

I’ve also tried to create a new dedicated share, also adding

Code

durable handles = yes
smb2 leases = yes

in extra options but nothing to do.

I can see here the suggestion to upgrade SMB at least at 4.22.7 version.

With OMV 8.0.8-1 I have SMB version 2:4.22.6+dfsg2:4.22.6+dfsg-0+deb13u1 -0+deb13u1

Is it safe to try to upgrade just SMB?

Do you have other solutions to try?

Display More

I cannot agree:

Also using macOS 26.2 w TimeMachine and omv8 --> no issue at all

But I changed some smb-Parameters in server/share sections to optimize the functionality between macOS and smb-shares.

Quote from ryecoaaron

it shouldn't do that on every boot. That is an even better reason to remove the package if the RPi foundation does have it configured to do that.

it does - definitely. Read my initial post. I tested this exhaustively - and it took me hours of research to find out whats going on.

Whenever cloud-init finds a changed /etc/hosts (e.g from omv) at boot-time, it replaces it with its own (and data taken from user-data).

This is caused by the default setting of the variable manage_etc_hosts: true in /boot/firmware/user-data on Raspian - what is the opposite of what you can read in the more general cloud-init documentation.

You only can suppress this by:

1- editing /boot/firmware/user-data

2- disable cloud-init completely

3- removing cloud-init

... beside replacing /etc/hosts :-/

Quote from Markus49124

Leider habe kein BackUp Ich habe das System vor 3 jahren mal aufgesetzt und das leider übersehen

Wie sagt man noch? Aus Schaden wird man klug ...

Dabei ist das mit dem Backup-Plugin sooo einfach ...

Aber eine Neuinstallation geht ja auch schnell - nur die Konfig macht es meist aufwendiger.

Quote from chente

Yes, that's the ideal situation when a backup exists. I hope the OP has one next time.

From post #1 it was not clear for me if a backup is existing ... but if not you're definitely right

Ich würde einfach das Backup der defekten disk auf eine neue spielen, davon booten und alles sollte wieder da sein.

Just one info:

I removed cloud-init from my omv-test w the command stated - success --> system still working - as expected.

Some files from cloud-init are still on the system (like /boot/firmware/user-data and log files in /var/log/) , but this is no issue at all.

ryecoaaron All fine w me - I'm just pretty careful with my systems and trying to do changes only if I somehow understand the basics behind.

One question left from my side:

I was trying to find out how to safely remove cloud-init from my Raspi and couldn't find anything- just about negative stories from trying to do so on Ubuntu. At least it seems not to be a straight forward excercise ...

I would really like to give it a try and test it here on my Raspi omv-testsystem.

Could you provide the steps needed to remove it completely from my Raspi?

Quote from ryecoaaron

It isn't radicalI have a lot of experience with cloud-init. cloud-init is meant to configure a machine on first boot in most cases. After that, it shouldn't do anything. It actually will cause more problems than prevent. If you are going to just disable it, you might as well uninstall it. RPis have been running fine without it for years and my three RPis do not have it installed.

There we are just having another opinion: you don't find it radical. But you would delete a sw which is essential for the first boot and you're saying ".... in most cases its not used afterwards" and "it shouldn't do anything". And how about other cases? At least I don't know about them ...

And if you just disable it, I'm able to enable it again whenever its needed. If its deleted I can't.

In addition, RPi ran fine the last years w/o cloud-init because in the past they used other script-based methods for initial bootup and configuration. But those were replaced by cloud-init (as stated in the Raspberry blog)

Don't get me wrong. You're the expert. And if you say that cloud-init with their services is useless after the first boot, then I'll have to believe.

The only point I'll like to make: why not just disabling it if it doesn't hurt anybody? It would reduce risk of doing a wrong thing to a minimum and would leave the door open for everybody just like to enable it again if needed for some reason. In addition its a small package and doesn't cost anything in terms of needed space in system.

But its your decision and just my 2ct.

Now I'll be quite - and just waiting for things to come

I couldn't experience any issues so far w cloud-init installed but disabled.

Edit: and I think, before doing such a radical step, somebody should look into the real impact on omv if cloud-init is just installed but not running.

Quote from votdev

The most important qestion is why is cloud init installed outside a container on the host system? Is this Raspi specific? If yes, we need to disable that on OMV.

As I said: cloud-init is installed and activated as part of the standard Debian Image (Debian Trixie 64bit Lite) with Raspberry Pi Imager.

I think this is Raspi specific - but only installed w new images, not within an upgrade e.g. omv-release-upgrade which includes a debian upgrade.

• If a complete 'disabling' of cloud-init really makes sense or is feasible - I can't judge.
• There are about 10 to 20 managed services by cloud-init on Raspi, but I'm not experienced enough for evaluation.
• It's pretty easy to disable cloud-init as a whole (shown above) or just disable management of /etc/hosts.

I tested both disabling options and I could not observe any issues with the system.

HW/SW: RPi 4b, Raspian w Trixie, OMV 8, brand new standard installation

Issue:

When changing the hostname through omv-gui this will be active till the next reboot.

After reboot you can observe that the /etc/hosts managed by omv was changed by cloud-init and the hostname is changed back to the initial hostname set within installation procedure of Raspian (Raspberry Pi Imager).

The whole issue is caused by cloud-init which is part of the current Raspian (Trixie)

One solution for the issue mentioned is to edit /boot/firmware/user-data and to change the entry manage_etc_hosts:  from "true" to "false"

This will leave /etc/hosts untouched within the cloud-init procedures at bootup.

IMHO it would be better if omv would handle this conflicting situation (Configuration mgmt through cloud-init vs omv) because omv is installed on top of an existing OS

Another workaround would be not to change hostname through omv-gui.

Or to deactivate cloud-init at all by sudo touch /etc/cloud/cloud-init.disabled

votdev Thanx for your answer.

Although you say its "normal", I would say "its normal because its programmed in this way".

IMO its not what a user can expect as a result of just changing owner of a shared folder in a section of the gui which is described and documented as "just using/changing standard linux-owner/permissions" (see post #1). From my understanding ACLs are not standard ... but maybe I'm wrong.

But ok - you're the owner - then I'll have to proceed using the mentioned "ready to use patch" with just 7 code-line changes, use the reset perms plugin or the terminal to get the results I'm expecting.

Again: many thanx for your quick reply!

ryecoaaron  votdev

It would be really great getting just a quick answer - even if its just one sentence like "you're right and we should work on this" or "its a feature and planned behavior"

Many thanx!

Yesterday a colleague of mine (lisanet) wrote a small patch for sharemgmt.inc (just some lines to be changed)

I tested this successfully on my omv-system 8.0.6-1 and now system behaves as expected (at least in *my* eyes):

1- create shared folder -> no default ACL

2- change Linux-permissions in "File Owner and Group" on ACL-Tab -> no default ACL added

3- define named ACL in "File access control lists" on ACL-Tab -> default ACL + named ACL (ACLs added)

4- remove/uncheck named ACL in "File access control lists" on ACL-Tab -> no default ACL + no named ACL (ACLs deleted)

It would be great getting feedback from developers - at least if the described behavior described in #1 post is a bug or feature

I'm having a question because I don't understand the behavior when creating a shared folder and changing the owner/group/permissions afterwards.

What I did

1- create a shared folder (through omv-GUI) "test2" (using just default settings)

Result when watching at it in terminal:

drwxrwsr-x 2 root 4096 Jan 10 17:05 test2

Fine. No issue. As expected

2- change ownership of this shared folder to 'jt' (my unix-login) through omv-GUI (ACL-Tab, Top section (standard Linux-Rights), NO CHANGES to lower section(ACL))

Result watched in terminal:

drwxrwsr-x+ 2 jt 4096 Jan 10 17:05 test2

Owner is now jt as configured, BUT there is an ACL added.

This is not what I expected and described in another way in doc https://wiki.omv-extras.org/do…omv7:nas_permissions_omv7

There its documented in section "Shared Folder Permissions":

• The field that is labeled File, owner and group (above) assigns Standard Linux permissions.

Questions:

- Did I something wrong or is it just a misunderstanding?

- Why is it not possible within this ACL-GUI-page to remove ACLs and I need setfacl in terminal or the reset perms plugin to remove them?

Thanx in advance.

Upgraded yesterday my RPi4 OMV System --- absolutely no issues.

Thanx!