majbom

Members
 View Profile  See their activity

  • Posts

    32

  • Joined

  • Last visited

 Content Type 

Posts posted by majbom

    Server almost unusable due to full cache drive

    in General Support

    Posted

    Hi.

    Apparently I have something installed or setup so my cache drive is filled to the limit; 0 bytes left 😞

    Now I'm not able to start the Docker service and my VMs seems gone 😢

    I have tried to move all shares away from the cache drive, but it doesn't help. I would've liked to run QDirStats (to help me solve what is going on and clean up), but as my Docker service is down, that's not possible.

     

    Where do I go from here?

    Please tell me what info you need to give a hint.

     

    Thanks

    [support] dlandon - Logitech Media Server

    in Docker Containers

    Posted

    On 8/23/2021 at 4:09 PM, dlandon said:

    That's a LMS log, and not the container log.  Probably best to get support from the LMS developers.

    One last question:

    I found out that the unwritable directory (/config/cache/tmp/) had "root" assigned as both user and group. So I tried to uninstall the container, wiped the directory in appdata and installed the docker again. But it's still the same.

    Isn't that wrong? And is it in the container or the LMS the error exists?

     

    Thanks

    [support] dlandon - Logitech Media Server

    in Docker Containers

    Posted

    I may have found a problem;

    I have these 

    [21-08-20 14:43:22.1482] main:: ([undef]) Warning: [14:43:22.1481] EV: error in callback (ignoring): Cannot write to '/config/logs/server.log': at /usr/share/squeezeboxserver/CPAN/Log/Log4perl/Appender/File.pm line 241.
[21-08-20 14:43:22.1482] main:: ([undef]) Warning: (in cleanup) Cannot write to '/config/logs/server.log': at /usr/share/squeezeboxserver/CPAN/Log/Log4perl/Appender/File.pm line 241.
[21-08-20 14:43:22.1488] main:: ([undef]) Error: Select task failed calling Slim::Networking::Async::HTTP::_http_read_body: Error in tempfile() using /config/cache/tmp/XXXXXXXXXX: Parent directory (/config/cache/tmp/) is not writable

    for every 8th millisecond 😬

    Share uses cache-drive although it shouldn't

    in General Support

    Posted

    2 minutes ago, itimpi said:

    Actually I would probably recommend setting the 'videos' share to Use Cache = Yes as that way you maximise downloads speed initially but then mover later transfers the video material across from the cache to the array which is its long term home.   Having said that you want to optimise for your actual expected usage pattern across the Unraid server as a whole.

    Done - thanks for the tip!

    Share uses cache-drive although it shouldn't

    in General Support

    Posted

    11 minutes ago, itimpi said:

    Does the Downloads share use the cache?   If so that is expected behaviour when using Krusader as it works at the Linux level and is not aware of User  Shares and can bypass them.   As far as Krusader is concerned  both source and destination are on a common mount point of /mnt/user so it tries initially to do a 'move' (i.e. rename) for speed and only if that fails does it try a copy + delete operation.   The 'move' operation will leave the file on the same disk thus explaining your symptoms.

     

    The solutions are to either do a copy + delete in Krusader, or set the 'video' share to Use Cache = Yes so that mover will later move the file from cache to array.

     

    The Download share does use the cache. Actually I had it written in my post, but deleted it again, as I figured it couldn't be that :D

     

    I think I'll disable cache on Downloads then, as I don't want it to be filled with "video"-stuff, leading to other shares can't use it.

     

    Thanks for the clarification! :)

    Share uses cache-drive although it shouldn't

    in General Support

    Posted

    I've tried to re-install Krusader (including removing the folder from appdata), as I suspect it to be the problem.

    But the problem remains.

    The files shows up on the cache drive (/mnt/cache/video/) when I move files (with Krusader) from a share on /mnt/user/ (/mnt/user/Downloads/) to another share on /mnt/user/ (/mnt/user/video/)

     

    The "video" share has following settings:

    "Use cache" - "No"

    "Included disks" - "Disk 1, Disk 3"

    "Excluded disks" - "None"

    and there is over 1TB free space on Disk 1 + 3.

     

    What am I missing?

    Share uses cache-drive although it shouldn't

    in General Support

    Posted

    On 11/13/2018 at 12:11 PM, John_M said:

    Perhaps something (a docker container, for example) is configured to write directly to the cache. Maybe you have a mapping that points to /mnt/cache/video instead of /mnt/user/video. There's no need to run Unbalance to move the files. Change the setting to "use cache drive: yes" and run the Mover, then set it back to "use cache drive: no". Occasionally a setting might get corrupted if there's a problem writing to your boot flash device so toggling it to "yes" and back to "no" can fix it. Post your diagnostics.

     

    I think I found the problem;

    Krusader was using "/mnt" instead of "/mnt/user".

    Share uses cache-drive although it shouldn't

    in General Support

    Posted

    Hi

     

    I got this message from Fix Common Problems: "Share video set to not use the cache, but files / folders exist on the cache drive". So I checked the settings which were correct ("use cache drive": no). I moved the files using unBALANCE, and finally removed the folder "video" from the cache-drive. But after I moved some files to my video-share, it uses the cache drive again.

    I have 2 4TB HDDs; one is completely full and the other has a lot of free space (> 2TB) - both of the drives are included for the video share.

     

    Why does unraid keep using the cache drive for this share?

     

    Thanks :-)

    Empty disk is not empty

    in General Support

    Posted

    Well, misfortunes rarely come singly. I have now tried to shutdown the array, to "change config", but it seems that a few docker-images hangs on shutdown :(

    I have tried to shutdown/reboot from dashboard, but nothing happens.

    Last I have tried shutdown from SSH, and now the webui refuses connection. The shares are still accessible, and I can still SSH into it.

    What to do?