murkus
Members
-
Joined
Everything posted by murkus
-
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.
-
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.
-
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. 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.
-
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. 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.
-
from the initial post it seems that unraid is the nfs server and some debian 11 as nfs client. however - and this is often overlooked - when stat and locks are used, the nfs server (here unraid) will want to send data to statd and lockd on the nfs client, here the debian 11. i.e. you need to fix the port numbers on the debian 11 and then allow them in the host firewall i.e. for unraid to send to rpc, statd and lockd. to be explicit: even if unraid is the nfs server, the nfs client als has server roles for stat and lock and you need to consider this for your firewall design. I am not sure that this is the problem here, but as this stuff is often overlooked I mention it, just in case that it may be the cause that unraid cannot reach statd and lockd on the debian 11 client.
-
just a hunch: have you checked whether your unraid server can reach the lockd on the clients?
-
I have not tried to use NFS for VDIs, but as a "Remote", which is what is a share for backups in XCP-ng. The backup writing works, but the health checks fail in the most cases with: Error: SR_BACKEND_FAILURE_47(, The SR is not available [opterr=[Errno 116] Stale file handle I have not idea why this happens. If I remove the Remote and re-create it, the back works with health check for once. Next time when scheduled the problem re-appears. If someone has a solution, please step forward.
-
I am going through a very frustrating moment because of the way CA backup is ordering the stopping and starting of containers. normally, as I understood unraid, for starting the order of the containers in the UI list is used. And of course this has a deeper meaning, if you have container dependencies. Why the '*/%§§ is CA backup using an alphabetical order, which is of course not the same as in the UI container list. This caused that Mariadb was stopped before the depending application and so the database was corrupted. I would strongly mandate that CA backup should use gthe same order as unraid does for starting containers, and the inverse order for stopping the containers (i.e. the same order that unraid uses to stop the containers). Anything else will lead to disaster for some users!
-
The problem I describe here started to appear after updates in Q4 2022. Earlier versions (sorry I do not know the exact version number when this problem appeared) of unraid did not have this problem. I can 100% reproduce the problem in safe mode (no plugins) and in normal mode. I have created diagnostics which I make available directly to the unraid developer upon request. The problem only occurs on the unraid array (this unraid is a bare metal installation). When making ghettoVCB write through NFS to a USB drive (using the Unassigned Devices plugin) the problem does not occur. This is why I assume the problem is somewhere with the unraid fuse driver for the virtual array. ghettoVCB is a backup script then runs directly on ESXi hosts and creates snapshots of specified VMs to some NFS storage. I have been using unrad for a long to as the target NFS storage for this. Now this doesn't work any more for me. The problem description follows: The problem occurs when ghettoVCB is cleaning up old backups that ran out of the defined retention. The cleanup code uses the rm command, which will hand in en endless loop creating .fuse_hidden* files. I am aware what the function of -fuse_hidden* files is and I have checked with lsof whether there is a process keeping any of the files open that ghettoVCB attempts to remove. None of the files is open before ghettoVCB is executed. During executing of ghettoVCB the problem happens so fast that I was unable to check with lsof. I have added additional debug logging to ghettoVCB to identify the exact code which is having the problem: In function checkVMBackupRotation() there is the following command that removes old backups that ran out of the retention: logger "debug" "Removing $BACKUP_DIR_PATH/$i" rm -rf "$BACKUP_DIR_PATH/$i" RETVAL=$? The rm command will spur an endless number of .fuse_hidden* files. unraid seems to think that some process is keeping some file(s) open when it is supposed to be deleted and renames/copies the file to fuse_hidden... And rm seems to iterate until all files are removed, and possibly tries to remove the renames -fuse_idden* file, which generates another .fuse_hidden... file. This process does not end on its own. This way ghettoVCB cannot be used in the mode where it handles backup retention on its own. Note that ghettoVCB contains work-around code to work properly with slow NFS NAS devices. This code is -NOT- involved where the problem occurs. I tried to add the work-around right before the problematic command. No amount of sleep time would work around the described problem. It would be great if this problem gets fixed, as I cannot currently use the parity protection of the unraid array for my ESXi backups - as the backusp only fully work on non-array storage currently.
-
I see, thanks for the offer. I'll try to fix it on my own, as I don't use twitch and I don't intend to join that. But if it helps I woul dmeet you on Matrix or Discord. The Library scan button seems to work. I found a corresponding log in the tmp folder where the fifos are.
-
OK OK OK, this explains why shit doesnt work well... I did actually change the name of the fifo and created four of them in the mopidy config manually. Of course everything is jumbled up now.
-
you wrote: "Did you know that the Mopidy app has the ability to dynamically create multiple instances AND automatically add and remove that instance as a stream source in snapcast over HTTP?" That sounds great! I would like to understand how I may use that.
-
I did not have source = in the config file. Thanks for the example file, it is more self-explanatory. I will use that and edit it to include my old config settings Also edited the server.json and put it in the config path on appdata. it seems that it is read when restarting the server. I still get tons of these: [Notice] (handleAccept) ControlServer::NewConnection: <ip> Error] (cleanup) Removing 1 inactive session(s), active sessions: 2 I also clicked on Settings > Scan Library and it displays a pop-up saying "Scanning local library" with a spinner. I don't know whether it is effectively scanning the library, though.
-
OK I have not updated again. for completeness: I am seeing these in the snapcast log, a lot: [Error] (cleanup) Removing 1 inactive session(s), active sessions: 2
-
I installed the update of today (both of your snapcast and mopidy3 containers). Now it doesn't work fully any more. the SnapWeb UI says: The resource '/' was not found. What did you change? What do I need to change in my config? In the meanwhile I would love to go back to the previous version for both containers, but you seem to have removed them. There is only "latest" and no other tags... frustrating. I suggest you give every version of your containers a unique tags and let the "latest" tag point to the tag of the latest version, so that people can go back to an older version if they have problems with the latest container.
-
we have been through this discussion several times and the result is: sorry, but no. I'd only make them available to you personally and not for sharing.
-
I installed the second fix update and now the SMB/NFS shares where shring was off, are still shared out. Now it became worse: I cannot manually turn this off by enabling and again disabling Sharing! I'm afraid we're not yet there...
-
I installed your update and then it happened again. Not sure if your update really fixes this...
-
correct. the share switches were "off", still the sharing did happen. so this is consistent with what you found.
-
If you say so. You have been informed. Thats all I can do.
-
today I had the occurrence that the director process died. no information on that in the bacula.log or system log. so I restarted the container. naturally a lot of the processes that were waiting were displayed to be in error. So I clicked the restart button on them in the history list in relatively quick succession. The director died again. I can reproduce this, if I restart - say 5 or more - jobs from the history without waiting for each restart button spinner to finish, the director will die and some bconsole processes will complain. If I wait for the spinner to finish before I restart the next job, the director will stay alive. I would be interested whether anybody else can reproduce this behavior.
-
yes is is set to No. Remember, the Share setting got changed for the shares that were mounted from remote servers, not for USB devices. Hence, I do not see the connection of the question to the issue.
-
After I updated to UD 2023.04.15 I found it behaved differently in the following aspect: I did not enable "share" for any of the unassigned devices or mounted SMB or NFS shares. So as expected, before the update, none of these were shared. After the update, the mounted SMB and NFS shares are all shared via SMB (haven't checked NFS). Is this intentional? To me this is unexpected and I don't know how to turn this off, as "share" is already for all the mounted SMB and NFS shares. I found that if I enable "share" and straight away disable "share", this will make the sharing go away again. So, fixable, but at least unexpected and I suspect - also unintended.
-
This is obviously a XO noob question, but it would strike probably everyone who is new to XO: When starting the container and opening the web UI there is a red questions mark in the XOA menu section. also other sections as Hub and XOSAN say "Try XOA for free and deploy it here". My current (and possible incomplete or wrong) understanding is that this container is an instance of XOA. So what would happen if I went through the procedure to deploy XOA through the containers XO web UI? would this overwrite parts of the container? Is this encouraged or discouraged? Also if one would run through "deploy XOA", would the Updates button then be usable and do the "right thing"? Or is it discouraged to use Update in the Web UI and rather pull a new version of the container? As there is no information on these in the container description, I am unsure how to proceed here, as I do not wish to cripple the container accidently by deploying XOA and using Update.
-
vchanger in latest is working fine. Thanks for the effort.