murkus

It may well be that UD was pinging servers, but if servers didn't respond to the ECHO request this did not have any consequences on the UI, the servers were not shown as "down". Later versions then set the server as down when not reachable and the mount wouldn't work. At that point I did not only need to allow SMB and NFS gthrough the firewall, but also ECHO requests. Now I realized that missing ECHO responses didnt have any consequences on the UI any more, as it was the case in early versions. This is why I said: again This is my perception and experience. You may disagree. Just explaining.

Using version 2024.01.17. I am experiencing 2 things (1) the some Mount buttons are somehow "blocked" or unresponsive (while being shown in orange) for a whole, and then suddenly become responsive. The group of unresponsive buttons changes over time and I have not seen a pattern here, yet. This has not happened in earlier, although I cannot say with which version this behavior was introduced. (2) in earlier versions file servers were shown as "off" or "grey" indicator if they couldn't be pinged by the plugin. This doesn't seem to be the base with the version mentioned above. Has this behavior been changed again?

Yes, I realized that. I have redirected all my docker logs on all hosts to go to a central syslog. The web UI logs are not really of interest to me in the central log repo and I would need to suppress those. You probably have a reason why you think it is better to have those in the docker logs. I personally liked it the way it was before, but that's just me.

Thanks for including pg_dump 16!

@VRx is there a chance that the pg_dump binary gets upgraded to 16.1 in the bacula 13 postgres containers? currently the catalog backup fails for everyone using Postgres version higher than 14 with bacula 13. 07-Jan 23:45 bacula-dir JobId 18092: BeforeJob: pg_dump: error: server version: 16.1 (Debian 16.1-1.pgdg120+1); pg_dump version: 14.10 (Debian 14.10-1.pgdg110+1) 07-Jan 23:45 bacula-dir JobId 18092: BeforeJob: pg_dump: error: aborting because of server version mismatch 07-Jan 23:45 bacula-dir JobId 18092: Error: Runscript: BeforeJob returned non-zero status=1. ERR=Child exited with code 1

Good work, got it up and running. Thanks for the effort!

If someone wants to use a more recent version of Postgres than 13, Baculum 11 (as provided in this container) will throw an error. Baculum 13 contains a fix: https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/commit/e1389d3caf89875c0009930237ba59a1133f6cd6 This fix also works with Baculum 11. You may manually edit the file in the container. More ideal would be if the fix could be incorporated by @VRx for updates of the container image. Just my 2 cents.

I am seeing this the first time today (I checked back for the last 6 months), although there are no new SMB exports or mounts and unraid has been updated to the latest stable version a while ago. The time it started to appear in the logs seems to coincide with when a macbook started to backup to unraid using TimeMachine (which is using an SMB disk share). The macbook does this once every day, so I wonder why I didn't see this log entry earlier. Next day I saw that the flurry of this message ended when a backup of a SMB share ended that is hosted on a TrueNAS VM and mounted on unraid using Unassigned Devices in /mnt/remotes. This would mean these messages are actually coming from the SMB client on unraid. No idea why this would happen now and not earlier, no idea how to solve it.

Interesting, could you elaborate, please?

@VRx What is your strategy regarding providing images for available major versions? Are you waiting for the second next major version to appear before you work on the next major version? You currently work with 11. 13 is available some time and 15 betas are being relased. Will you look into 13 when 15 has been relased (as non-beta)?

@VRx Has vchanger been put into the "normal" production images or is it still only part of the beta images?

Breaking changes are generally unwelcome.Nobody said it is difficult. It is just not good UX, as it becomes tedious with a lrger number of shares being mounted (e.g. for backup reasons). We may agree to differ in opinion.

torprivoxy container recently started to flood my log with these: [warn] Socks version 71 not recognized. (This port is not an HTTP proxy; did you want to use HTTPTunnelPort?) What does this mean? Why does it happen? What needs to be fixed?

Yes, it DOES work. But with the rationale applied by you, you'd use the "search" definition and remove all local TLDs that are mentioned there. But you may end up with ambiguous hostnames, if the same host names exist in different of these TLDs. I personally don't think that it makes a substantial performance improvement. You can prove me wrong of course. I would still prefer the FQDN being used, if the user chooses to put that in. At the least it should not refuse to use the FQDN if that is in the config file, as this is how it was in the past here for me and I had to edit the config file manually.... (faster than deleting and creatig the shares again). the BUG part for me was that after a reboot UA refused to recognize the existing shares. It should at least have corrected those entries on its own and not just say nay. It was suboptimal UX.

I daresay there is again a bug with the smb config file handling (some may call it a feature). After rebooting the unraid server, UA found all SMB and all NFS share mounts that are in the same DNS domain to be invalid. The cause seems to be that the entries contain full domain names (FILER.SUB.NET), and if I create a new smb / nfs mount, it will just use the hostname (FILER), even if I specify the server by full domain name. I actually would prefer it if UA uses the actual name provided by the user and wouldn't insist on throwing away the rest of the FQDN. Note that I wrote that this is only happening for the servers that are in the same DNS domain. What do I mean: UNRAID.SUB.NET -> DNS domain is SUB.NET FILER.SUB.NET -> is in same DNS domain, UA wants it to be just FILER FILER2.OTHER.NET -> is NOT in the same DNS domain, UA accepts it as FILER2.OTHER.NET has this to do with domain in /etc/resolv.conf somehow? here for sake of the example: domain sub.net search sub.net other.net other2.net

Thanks for fixing the bug, it works again here!

I have sent it, the file on the system has never been edited manually.

sure

So if a share designtor is [peep.poop.net:/mnt/foop/feep] can I just edit it manually in the config file? Which characters should be removed from this designator? How may I restart UA without restartung the machine or array?

you mean /boot/... ? should I just remove the NFS blocks in the config file? this would encomass restarting the machine? or could this be done be restarting some component of UA?

samba_mount.cfg? we ares till talking about NFS shares, right?

I dont know what you mean by device designators, but the export path/filenames only contain letters, number, dashes and underscores, nothing else. I wouldn't know why this should not be acceptable names and renaming them would be quite an effort as they are mounted by a lot of other machines, too.

remote NFS shares have "Invalid configuration - Remove and Re-Add", but I cannot remove the share from UA (the "x" button does not remove the share). What now, how to fix?

I had given up on it half a year ago, after upgrading to 6.11. it was broken, so I thought. I gave it a shot now with 6.12.2 with what I think made the substantial difference: I now use a "disk share" instead of a regular "user share". Disk shares may not yet be enabled on your unraid installation and this can be done in "Global share settings". The disk share has a size limit for timemachine. I don't see any substantial drawbacks of using a disk share as compared to a user share, if you plan to have you macOS backups all on one disk anyway. The SHFS user file system turns out to come with a lot of performance overhead and I have stopped using it for any shares for backup solutions. I am using the unraid TimeMachine that is included with the OS, not the TimeMachine container. I had tried the container in the past and that was also not successful for me. I removed all custom tweaks for SMB, I am using the stock SMB config that 6.12 comes with. TimeMachine now is not perfect, but it works: The inital backup stopped like 4-5 times and I had to restart it. The whole process took 2-3 days until the initial backup did conclude successfully. Starting new differential backups works fine. I don't know yet whether the verification will be successful, as it is currently running. If it fails I will provide an update here.