Beiträge von Reed

    I've had a random hang that has occurred about 4 times total when transferring large amount of data from Windows 8.1 or Windows 10 to OMV.


    OMV to Windows 8.1 (SMB): No problem!
    OMV to Windows 10 (SMB): No problem!
    Synology NAS to OMV (NFS): No Problem!
    Windows 8.1 (SMB) to OMV: Random Freezes
    Windows 10 (SMB) to OMV: Random Freezes


    Always the random problem comes when transferring from Windows 8.1/10 to OMV over Samba. Sometimes it finishes the copy okay, sometimes it hangs. Randomly Windows copy progress freezes and OMV becomes unresponsive. Can't access it through the main Web GUI and I have to power it down at the machine with the power button. It does recognize I hit the power button and shuts itself down via software.


    The board is new ASRock N3150DC-ITX. New memory (Crucial 8 GB), new SSD (Samsung - Storage/Intel - OS), etc. The fact that the issue is asymmetric (issue is only to machine) and only happens with Samba (NFS is okay) leads me to believe this is a Samba issue. Perhaps either a network driver issue or a Samba issue.


    Any ideas on where to begin debugging it? Which logs to look at, ideas to try out? Thanks!

    I'm also getting a timeout. I installed it a few days ago and haven't been able to get it to come up in the broswer yet. Status says it is running. I've tried enabling/disabling a few times before I gave up and moved on.

    I find the simplest way to do this is to create a good backup, create the new system, then restore the data from the backup to the new system. It takes longer, but then you know its fresh and not using some legacy stuff from your old system.

    There is a bug in how 'Flash Memory' activates on a running system. If Notifications are enabled (postfix) when Flash Memory's does it's startup mounting/copy, it corrupts postfix. I'm guessing it is occurring because Flash Memory is moving around files that are actively being used by postfix.


    In the guide https://www.debian-administrat…/661/A_transient_/var/log, it recommends doing this at start-up before anything is active and using the files. I've also confirmed that if I disable 'Notifications' before enabling 'Flash Memory' this issue doesn't occur.


    I think the safest course of actions would be for 'Flash Memory' to not try to enable itself immediately on a running system, but to wait and enable it on the next reboot.


    To replicate:
    1) Enable 'Notifications'
    2) Enable 'Flash Memory'
    3) Check the status of postfix (postfix -status) or try to mail something. For me the mail queue froze and wouldn't send anything.

    There's a few items of feedback I'd give to the plugin owner:


    - Suggest to add pam-generic to the pre-defined jails list.


    - Suggest to add omv-gui to the pre-defined jails list.


    - Suggest both pam-generic and omv-gui are enabled by default when fail2ban is enabled.
    - Explanation: As a new user, I was expecting some basic protection when I installed the plugin and enabled it on the main tab. I was actually surprised when I later discovered I hadn't enabled any protection because I hadn't enabled the specific jails. It can give a false sense of protection if the user is inexperienced and fail2ban is enabled but no jails are enabled.


    - Suggest not allowing a jail to be enabled if the corresponding log file doesn't exist.
    - Explanation: As a new user, when I realized I hadn't enabled any protection I enabled all the jails and consequently fail2ban then failed to start. It seems fail2ban takes issue when you tell it to enable a jail and the log file doesn't exist for that jail.


    Anyway, take it or leave it, these are the suggestions/impressions from a fresh set of eyes. But I think it would improve the user experience.

    Okay, I have the solution.


    pr_bond: Enabling pam-generic I think is a good idea in general, it will catch anything that uses PAM (including SSH), however it doesn't catch the openmediavault-webgui failed login attempts.


    To make sure I wasn't replicating an existing filter, I did a search for its key items in all the filters in "/etc/fail2ban/filter.d" before creating a new one.


    New: omv-gui.conf

    Code
    #
    # Catch openmediavault-webgui Unauthorized logins
    #
    
    
    [Definition]
    failregex = .*\s+openmediavault-webgui\[\d+\]:\s+Unauthorized login attempt from\s+::[^:]+:<HOST>\s+.*
    
    
    ignoreregex =


    Settings in the GUI:
    Name: omv-webgui
    Port(s): http, https
    Filter: omv-gui
    Log Path: /var/log/auth.log


    I confirmed this works by failing logins and getting myself banned:

    Code
    root@openmediavault:/etc/fail2ban/filter.d# fail2ban-client status omv-webgui
    Status for the jail: omv-webgui
    |- filter
    |  |- File list:        /var/log/auth.log
    |  |- Currently failed: 0
    |  `- Total failed:     5
    `- action
       |- Currently banned: 1
       |  `- IP list:       192.168.1.11
       `- Total banned:     1

    I'm using the default ports.


    I set it to:
    Ports: http,https
    Filter: nginx-404
    Log Path: /var/log/auth.log


    I tried getting it to ban me by entering incorrect information, but it didn't ban me. Anything you can see I'm doing wrong?

    Has anyone configured a jail for login failures for the main OMV GUI? I see the failure attempts appear in the auth.log, but no jails are configured to look for these by default.


    Also, separate question. eXtplorer doesn't have a log that I can find. I'm assuming this means it would be impossible to for it to be used with fail2ban?

    Yes, that makes sense. I did confirm I only have read access for the OS drive. Also, since I created my shared folders with the default 'r/w r/w r' and the extplorer user is a member of 'users', there is already access for 'r/w' from the group setting without adding any privileges to the user.

    In the plugin it says "Give the extplorer user read or read/write privileges to any shared folder to be accessed in eXtplorer.". But without granting the extplorer user read or read/write privileges it already had access to all my shared folders, the whole OS drive in-fact.


    I feel like I'm missing something, did I do something wrong?

    Check 2 things:


    1) OMV: What permissions 'user' has in OMV under User -> privileges. Make sure they are right and make sure you have the correct user.


    2) In Windows it caches the username/password for network access. If it is trying to connect with a user name that doesn't have the correct permissions, this will need to be cleared out. (Substitute in your IP address and username below.)
    a) Close any open explorer windows showing the network location.
    b) net use \\OPENMEDIAVAULT /delete
    c) net use \\OPENMEDIAVAULT * /user:yourusername

    Having thought about this issue even more, I'm almost certain this is either a race-condition case from using the Flash Memory plugin or an incorrect copy back to disk of the log directory. There exists a certain period of time in between when the mounts are being setup and files copied over that a change at that exact instant would be lost. Also if the data isn't able to be copied back correctly the state will not be accurate.


    If the real files have a pending send and they are replicated before the mail is sent, the replicated file will send and it will be reflected in the replicated files. If the replicated files aren't able to copied back to the real files it will send the old e-mail again and again.


    I think something with the above permissions was preventing it from copying it back properly and thus it wasn't able to see that it had already sent the mail and was trapped into sending it over and over again at each boot when the real files were again replicated for the RAM drive.


    Just to note, I still love the Flash Memory plugin and will continue to use it. I think it's a great compromise between wearing out your drive and potential log data loss. I was just relieved to finally figure out what was causing this.

    I found that Plex processes were accessing my drive every 30 minutes just to update the main log saying it was running but doing nothing. I decided to try to copy the method used by the Flash Memory Plugin which uses folder2ram. I initially tried adding the Plex log directory to its config file and then executing a folder2ram -generate.


    It did generate the file, however, Plex has an extremely long path and it also contains a lot of spaces in the path which caused folder2ram to not execute correctly. I ended up having to manually remove the mutant named files that were mangled because of the spaces. This was just as well because adding it to folder2ram's config file would have lasted only until the next time the plug-in was updated. At that time any changes I had made would have been blown away by the update.


    Besides the spaces in the path, the only other gotcha to doing this is the size of the log directory. Plex seems fairly bad at keeping the size of its log files reasonable. In 3 to 4 days I had been using Plex it had managed to generate 24 MB worth of logs. The DNLA log in particular seems to be able to grow without constraint. My earlier attempts failed because the initial 16 MB size of the tmpfs drive wasn't large enough. Eventually I increased the size to 128 MB and I added in a log cleanup routine to delete the older logs (ie "*.log.[3-9]"). Additionally I added a daily cron job to sync the data back to the disk.


    Overview of what you need to do to implement:

    Code
    Place file: /etc/init.d/plex_omv_tmpfs
    chmod a+x /etc/init.d/plex_omv_tmpfs
    insserv plex_omv_tmpfs
    Place file: /etc/cron.daily/plex_omv_tmpfs_sync
    chmod a+x /etc/cron.daily/plex_omv_tmpfs_sync


    plex_omv_tmpfs


    plex_omv_tmpfs_sync


    Acknowledge/Sources:
    - folder2ram (Good implementation on OMV)
    - https://www.debian-administrat…/661/A_transient_/var/log (I learned a lot from this explanation)

    I was having some difficulty with a disk spinning up periodically and in the process of debugging it I created a small shell script which others might find useful if they have the same problem.


    What it does:
    - It writes out buffered data to the disk
    - Enables Block Dump Reporting
    - Puts the Drive into Standby (spin-down)
    - Then sits in a while loop waiting for the drive to spin back up.
    - When it does spin up it turns off the reporting and displays the messages relating to the drive you are watching.



    Run: find_culprit <drive>
    Example: find_culprit sdc
    (/dev/sdc is my spin disk)


    Output looks like this:


    So now I can see that the files:
    - Plex Media Server.log (in Logs)
    - com.plexapp.system.log (in PMS Plugin Logs)


    Were modified.


    In this case it was actually sync'ing the RAM directories back to the physical disk that woke it up (daily cron job). But this helps automate the work of finding what is accessing your disk and waking it up.

    I've now solved the original problem of disk access, but on a side note, I did find that SMART isn't respecting the specified "Check interval" I've entered into the interface.


    I've entered: 86400


    It is checking about every 1 hour and 40 minutes:

    Code
    Dec 28 16:47:32 openmediavault smartd[2543]: Monitoring 3 ATA and 0 SCSI devices
    Dec 28 18:05:28 openmediavault smartd[2665]: Monitoring 3 ATA and 0 SCSI devices
    Dec 28 19:47:05 openmediavault smartd[2546]: Monitoring 3 ATA and 0 SCSI devices


    Not a big deal for me now that I've confirmed SMART isn't the culprit for disk spin-ups, but an interesting observation.

    The solution I'm leaning towards is using the same method the flashmemory plugin uses to cache the log directory:
    /media/e5f80c22-2bd8-427b-88f5-cad32e84e464/plexmediaserver/Library/Application Support/Plex Media Server/Logs


    This uses folder2ram and seems like a good solution. Any better suggestions?


    My preference is:
    1) folder2ram with the log directory.
    Pros/Cons: Least impact in needing to relocate plex and any issues with updates to plex. Least wear on SSD main drive.


    2) Relocate whole cache directory to the SSD.
    Pros/Cons: SSD doesn't need to spin up but will wear on the drive over time. Maybe issues when I upgrade Plex and cache isn't in standard location.

    Looks like Plex (using syslog):

    Code
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 45025024 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 625215472 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 625215480 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:15 2015] jbd2/sdc1-8(1453): WRITE block 625215488 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:20 2015] flush-8:32(12127): WRITE block 608174472 on sdc1 (8 sectors)


    Plex Sync is the exact culprit. Note the fact it updates the log every half hour.

    I'd love to implement this as well if you can point me in the right direction. I did some preliminary searching on Google, but it didn't immediately connect me with what you are talking about.


    I have 8GB of memory, only 2% of which is utilized, so it sounds like a great use for my system resources.