Jump to content

SudoPacman

Members
  • Posts

    50
  • Joined

  • Last visited

Posts posted by SudoPacman

  1. 3 hours ago, ich777 said:

    Please keep me in the loop and let me know about your findings, I update the Mega container only from time to time to usually avoid such issues.


    Heard back from support.

    I suspect it might be due to differing versions of MEGA between the originator and the importer. I guess I'll see how it goes over the next few days... if it persists I'll try grabbing the debug logs.

    Response here:
     

    Quote

    Please make sure that you have installed the latest version of our Desktop app on all your computers .

    Please log out your account (go to your Desktop app interface - Settings - Account - Log out) and then reinstall the Desktop app from this link: https://mega.io/desktop (please DO NOT un-install anything, simply install again).



    [PS: Ensure you have your Recovery Key backed up in case you forget your password and need to reset it - https://mega.nz/keybackup]



    If the issue persists:



    - Exit the Desktop app and restart it.



    - If you notice that files aren't being synced, please open the "Sync" tab of the "Settings" dialog in your Desktop app and verify that the checkbox next to your synchronization is checked. Otherwise, please check it and apply the changes.



    - Check if you are syncing a drive with an unsupported or nor adequate filesystem type (VBoxSharedFolderFS, FAT/FAT32/exFAT or network drives). VBoxSharedFolderFS is not supported, FAT/FAT32/exFAT are not recommended and we are working on some issues detected with network drives, so you could still notice some inconveniences with them in the current version of your Desktop app.



    - Go to the "Network" tab, click on the "Change Settings..." button on the right side of the rate limit and ensure the checkbox "Use HTTPS for transfers that don't start" is ticked.



    - Also, if the transfer is very slow or it freezes, please enable desktop notifications: go to Settings - Notifications - enable "System notifications" to see if the Desktop app shows any informative message.



    - If you are experiencing problems during uploads or downloads, please also check your rate limit in the "Network" tab to confirm if you have set any.



    - If you are experiencing inconsistencies between the synced folders:

    from the Desktop app, go to Settings - Sync - Force a full scan.

    visit MEGA website (https://mega.nz), go to Menu - click "Reload your account" while holding the keyboard key Ctrl .



    IF YOUR ISSUE PERSISTS:

    1. Please start Terminal window, execute the following commands and send us the output - this will help us to identify your Linux distribution version.



    The first command: cat /etc/os-release

    The second command: uname -a

    Third command: cat /etc/issue



    2. Close the Desktop app (Exit).

    If for some reason you are unable to exit the Desktop app using its interface, please execute the following command in the terminal: killall megasync

    Please, ensure there is no the Desktop app process running afterwards (the output of the following command shall be empty: pgrep megasync



    3. In order to help us with the investigation, could you please start your Desktop app from Terminal window as:



    megasync --debug > ~/megasync.log



    (this will send all debug messages to "megasync.log" file located in your HOME folder).

    You can find a tutorial at this link:

    https://mega.nz/file/fzJwWLyI#Agb3KmWjrJb0FoDjZIxfBFd87p-mA9zmFtGpYUjsl38



    4. Then try to run the Desktop app and see if you are able to reproduce the issue. As soon as you see that the issue appears, please wait at least 10 minutes and only then close the Desktop app.



    5. Create and send us the following documents:

    - Video of the issue you are exactly experiencing, step by step.

    - Screenshot of: M on your task bar - Settings - Sync tab

    - Screenshot of: M on your task bar - Settings - Folders tab

    - Screenshot of: M on your task bar - Settings - Network tab

    - Screenshot of: Right-click on your local synced folder - Properties



    6. Please attach the screenshots and your "megasync.log" (found in your HOME folder) to this email.

    Please also mention if you are syncing a local, external or network drive and what is its filesystem type.



    If the file is large (over 2MB) please archive that log file or alternatively upload that to MEGA through a web browser and send us back the Link with key (including decryption key).



    Debug logs will greatly help us to identify and fix the problem.



    We’re looking forward to hearing back from you.
     

     

    • Like 1
  2. 7 minutes ago, ich777 said:

    Strange, I updated the container a few days ago to be on the newest version and someone reported a similar issue but somewhat different:

     

    But it seems to be fixed itself like the user reported a few posts above.

     

    Maybe they introduced a few more bugs than they solved with the new version (you can read the changelog here).

    Maybe it is worth creating a ticket at Mega itself and report the exact issue with a screenshot, the container uses the latest version: megasync_5.2.0-2.1_amd64.deb


    Cool, thanks. I'll take a look at that changelog and perhaps raise an issue there if cannot find it already being reported.

    • Like 1
  3. Hi ich!

     

    I've been getting lots of issues in the last few days with errors indicating "File fingerprint missing".

    If I resolve them I seem to get three copies of each file in the download queue. Quite strange.

     

    I have a feeling it's working fine for files that are in sub-directories though, but that could be coincidental.

    Any ideas?

     

    Cheers

  4. Got an update on this in case anyone else experiences the same thing.

     

    In a nutshell, it kept happening. I'd get through a preclear, then add parity and boom, at some point during the rebuild.

    This is on a practically new supposedly enterprise class 16TB drive, so I was suspicious.

     

    A mate at work suggested it could be PCIe lanes, since I'm using an older Intel i7 970 and X58 platform, and during a rebuild there is a lot of strain on the system, and I have a lot of drives (10 data plus 2 parity and 2 SSDs).

     

    I've been thinking about an upgrade for a while, and have now pulled the trigger on an AM5 based build on an X670.

    Expensive, but it's crucial to me that I can trust my server.

     

    Just finished a parity rebuild, and all seems good.

     

    Hope this helps someone else.

     

    Cheers,

    Pacman

  5. When future me finds this, again, perhaps I should note the answer rather than have to rediscover it.

     

    If set the IP of the network interfaces to automatic, and fix them in your DHCP server, the docker networks get their gateway set correctly.

    I changed motherboard, so the MAC address changed, so that's what caused it.

     

    Feels like a bug, but the workaround is fine.

  6. Okay, so changed cables, and the drive has been through a complete pre-clear, with pre-read and post-read and all looking good.

    This is what happened last time though...

     

    I'm going to add it as a second parity drive and let it build.

    I suspect it'll all go fine, and then next month during the scheduled check it'll fail, but let's see!

     

    You said the syslog did not contain any information on why the drive got marked as having read errors. Is this because it did not go back far enough?

    Anyway to increase how far back is recorded perhaps?

     

    Cheers

  7. Hi guys,

     

    After a little support here please, since this is the newest drive in my machine, and "has read errors" so has been disabled.

    I have replaced one set of SAS cables the other month, but there is another set that could be replaced if warranted.

     

    I'm confused in that you don't seem to get much information about what unraid thinks the issue is, other than has errors so has been disabled, unless I am just missing it from the logs or diagnostics.

     

    It looks okay from a SMART point of view, which worries me from an RMA point of view.

    It also went through the complete pre-clear process without issue.

     

    Any help appreciated.

     

    Cheers,

    Pacman

     

    monty-diagnostics-20230501-1020.zip

  8. Okay, thought I'd try your rtorrentvpn docker and same thing (just times out), which has led me to my opnsense firewall live view.

    Looks like an update there may have done something since I can see it getting blocked by the "default deny rule".

     

    Thanks for your help binhex, I really appreciate it (and love your dockers).

    I'll report back, but sure it's something this end now.

     

    Cheers

    • Like 1
  9. 17 minutes ago, binhex said:

    that looks like a clean start from the small snippet of the log you have provided, have you changed lan network range?, created more vlan's?, reconfigured firewall etc?.

     

    Yeah, I thought it looked clean too. No errors or anything. Strange.

    Tried different browsers, machines, OSes. Rebooted.

    Everything i can think of.

     

    No, nothing has changed wrt to network or vlans. It's all been setup for months and months now!

    It's on br0 and always has been. I've tried changing to bridge but see the same thing.

     

    I wonder whether forcing a reinstall of the docker image is worth trying?

    Is that just a case of removing it and adding it again?

  10. Been using this for months without issue, and then the last few days I cannot access the UI after starting the docker.

     

    I've tried renaming the appdata folder for it (copying the openvpn config into the new one it creates), and renaming the torrent and complete/incomplete folders in case that's a factor. Something weird is going on.

     

    I've also tried with debug on but that doesn't yield any clues.

     

    The last entry in the log is:

    2021-10-15 11:45:33,020 DEBG 'watchdog-script' stdout output:
    [info] qBittorrent process started
    [info] Waiting for qBittorrent process to start listening on port 8117...
    
    2021-10-15 11:45:33,131 DEBG 'watchdog-script' stdout output:
    [info] qBittorrent process listening on port 8117
    
    2021-10-15 11:45:33,155 DEBG 'watchdog-script' stdout output:
    [debug] VPN incoming port is 54846
    [debug] qBittorrent incoming port is 54846
    [debug] VPN IP is 10.3.112.113
    [debug] qBittorrent IP is 10.3.112.113
    
    2021-10-15 11:45:33,628 DEBG 'start-script' stdout output:
    [info] Successfully assigned and bound incoming port '54846'
    
    2021-10-15 11:46:03,163 DEBG 'watchdog-script' stdout output:
    [debug] Checking we can resolve name 'www.google.com' to address...
    
    2021-10-15 11:46:03,190 DEBG 'watchdog-script' stdout output:
    [debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.187.228'
    
    2021-10-15 11:46:03,191 DEBG 'watchdog-script' stdout output:
    [debug] Waiting for iptables chain policies to be in place...
    
    2021-10-15 11:46:03,200 DEBG 'watchdog-script' stdout output:
    [debug] iptables chain policies are in place

     

    Does anyone have any ideas?

    Has there been a recent update that may have affected anything?

     

    I am trying direct access, so no reverse proxy or anything like that to consider.

     

    Cheers,

    Pacman

     

     

    PS: Oh, and if I access the console for the docker I cannot see anything going nuts in "top".

  11. Hi,

     

    Could use a little help getting homebridge to work on a custom network type please.
     

    When I first installed homebridge I used the default Host network, got the UI up, logged in, and tried adding the homebridge to my Home app. It didn't work - it appeared to timeout.

     

    I'm guessing this might be because my Apple TV, and many other devices are on an IoT VLAN (including the Sonos Play:3 that I want to use homebridge for).

     

    I have a network setup that some dockers can use to be on the same vlan. This is br0.3.

    It works fine with the dockers I have tried it on, but when I try and switch the homebridge to this network it appears to do nothing. I get no IP in the docker list, no logs. If I delete the homebridge folder in appdata it gets recreated but no config.json created.

     

    Any ideas what's going on?

    Has anyone got it running on a different network type other than host?

     

    Cheers,

    Pacman

     

    Edit: If pick br0 and fix the ip to something in the main LAN network I can access the UI.

    Still no dice on br0.3 though, even when fixing IP.

  12. I would be interested in seeing your proxy config from Nginx Proxy Manager, since I'm in exactly the same boat.

    I've searched and searched, looked at all kinds of examples, tried adding environment vars to change the web socket port, and it just will not work through the proxy. Works fine using internal IP.

     

    I have loads of reverse proxies working in SWAG, but cannot get this one to work. I tried migrating to NPM a few months back but it kept on corrupting configs for some bizarre reason so gave up on it.

     

    Cheers

  13. 19 minutes ago, binhex said:

    It looks like v3 has now dropped and therefore I need to modify some bits and pieces to to get the image working again. I shall take a look at this tonight.
     

    Thanks, much appreciated!

     

    I'm guessing that similar might be happening with Sonarr soon too then?

×
×
  • Create New...