Beiträge von ne20002

Zitat von nrand

If you had to change two line I have a different solution, which is more compatible with older scripts it turns out.

Remove the previous fixes and change the following in /usr/sbin/autoshutdown, line 1151.

Code

From: '$1 ~ regex && !/SLAVE/ {print $1}')

To: '$1 ~ regex && !/SLAVE/{sub(/@.*/,"",$1); print $1}')

The script the will now dropped the '@<interface_name>' from the network interface identification throughout the script. For example: 'eth0.42@eth0' would know as 'eth0.42'. This is similar to what it used to do I think. Can you give it a try and double check it form me. If this is good I will get the release out with the fix.

Thanks again for doing this for me

Alles anzeigen

Funktioniert.

It now works as expected. After wakeup the eno1.42@eno1 is checked a few times for an IP address and then it states 'Script started' ..

I changed the line 1126 and the same pattern one line below.

It now starts (automatically, triggered somewehre?) with the following output:

 Feb 19 14:54:45 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): ------------------------------------------------------'
Feb 19 14:54:45 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): Find available network interfaces and their IPv4 addresses'
Feb 19 14:54:45 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): 'eno1' has IPv4 address: 192.168.41.22'
Feb 19 14:54:45 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): 'eno1.42@eno1' status: up, IPv4 address: N/A, retrying in 5s ...'
Feb 19 14:54:50 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): 'eno1.42@eno1' status: up, IPv4 address: N/A, retrying in 5s ...'
Feb 19 14:54:55 u-nas autoshutdown[2390]: root: INFO: '_check_networkconfig(): 'eno1.42@eno1' status: up, IPv4 address: N/A, retrying in 5s ...'

The eno1.42 is used for a VM and normally not assigned any IP ..

On my system autoshutdown service chrashes at startup. This is the log output:

Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_config(): Kernel 4.19.0-14-amd64 supports power management modes:'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_config(): Kernel supports: HIBERNATE (suspend to DISK)'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_config(): Kernel supports: SUSPEND (suspend to RAM)'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_config(): Kernel supports: HYBRID-SLEEP (suspend to RAM and DISK)'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_config(): SHUTDOWNCOMMAND is set to: systemctl hibernate'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_networkconfig(): ------------------------------------------------------'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_networkconfig(): Find available network interfaces and their IPv4 addresses'
Feb 18 20:42:08 u-nas autoshutdown[2989]: root: INFO: '_check_networkconfig(): 'eno1' has IPv4 address: 192.168.41.22'
Feb 18 20:42:08 u-nas autoshutdown[2989]: /usr/sbin/autoshutdown: line 1127: /sys/class/net/eno1.42@eno1/operstate: No such file or directory

The file directory does not exits, the correct path would be:

/sys/class/net/eno1.42/operstate 

The path followed sysmlinks is

/sys/devices/virtual/net/eno1.42/operstate

How can I fix the '@eno1'?

Hi

I have upgraded my NAS with a fresh install of OMV5. And added the users for access to shares. So far so good.

I then mouted the data disks from OMV 4 and I now have a few problems with file permissions on the shares.

What's the best/correct way to fix file/folder permissions and ACL on data drives?

This is what I thought. But why?

I use Firefox and connect to the pi-kodi by its name. A host query on my maschine gives me three IPs for the pi-kodi: one IPv4, one IPv6 ULA and one IPv6 with public prefix.

It also happens on a very few pages only. Right on/after the login and when going to System Information -> Performance statistics.

If I connect to the pi-kodi by IPv4 or IPv6, everything works fine.

As this behaviour only happens on OMV 5 (i have two pis), never happened before with OMV 4 (where I didn't had IPv6) and does not happen at all on any other system or web-site, I wonder where the problem is.

Hi

I've setup a new Raspberry Pi 3+ with OMV 5 and have problems right after login. Not allways, but often Just right after clicking I get this:

Error #0:

OMV\HttpErrorException: Invalid IP address. in /usr/share/php/openmediavault/session.inc:185

Stack trace:

#0 /usr/share/php/openmediavault/session.inc(207): OMV\Session->validateIpAddress()

#1 /var/www/openmediavault/index.php(34): OMV\Session->validate()

#2 {main}

Raspberry has been set up with newest Raspbian and with the install script as mentioned in the documentation in the download area for single board computers. The only thing I chnaged is that I reenabled ipv6 as this was not working after installation. Following another thread I changed in /etc/sysctl.d/99-openmediavault.conf the

# Enable/Disable IPv6

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

to 0. With this change I get correct IPv6 (public and ULA), with correct routing and listed in DNS on the router.

But it now kicks me out sometimes and I wonder if this is due to the different ip addresses (which shouldn't be a problem). So is there maybe some of the UI pages relying fixed on IPv4 maybe?

Any help welcome.

King regards

S

I tried this and it worked roughly (as macvlan does have issues with multicasts). I have it solved by stopping the container and create a copy with newly assigned host network. Seems as if I can't change network on deployed containers.

Hi

I need some help setting up a containter with tvheadend. I use linuxservers/tvheadend and they state that if one needs multicast (I do) the container needs to connect to host network (and P flags needs to be removed).

I didn't manage to do so in OMV 5 with portainer.

Every time I try to join the container to host network, it says: container cannot be disconnected from host network or connected to host network.

As I'm new to docker/portainer,any help is highly welcome.

Kind regards

S

I'd also like to have the hardware monitoring for my nas. Sensors are in place and even show up in syslog. But a plugin serving the charts would be very helpfull.
Also, fan control would be really appreciated.

Would give a donation for this.

Basically this is a feature I'd like to see as well.

I have just set up a omv server (replacing my WHS2011) and I start to love it. Even as I see there a few things missing ..

I have a pi as an always on controll server for home automation and I'd like this device to monitor the UPS (as is is always on). But on the UPS there is also the OMV NAS. Which could be shut down if the plugin would support remote monitoring. I may also think of a szenario where I have more than one UPS serving different devices. So my whish would be:

* Allow more than one UPS to be monitored (with that tabs in OMV?)
* UPS can be local or remote.
* Define how the computer shall act on a UPS message (usually shutdown) per UPS
* for local UPS allow remote monitoring

That should serve nearly any requirement one can think of.