Package Center : The available disk space of this system is insufficient


Recommended Posts

Hi,


I'm currently running DSM 6.2-23739 and when I try and install a package via Packer Center I get the following error "The available disk space of this system is insufficient". As you can see from my screen shot their is 2.71TB of disc space remaining?

 

 

radarr.png

 

Thanks in advance


HEADRAT

 

Edited by headrat
drop
Link to post
Share on other sites

It's because /dev/md0 is full:

admin@Filmstation:/$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.3G 0 100% /
none 7.9G 0 7.9G 0% /dev
/tmp 7.9G 348K 7.9G 1% /tmp
/run 7.9G 3.7M 7.9G 1% /run
/dev/shm 7.9G 16K 7.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/md2 21T 19T 2.8T 88% /volume1

but I'm not sure what it does or how to empty it!

Link to post
Share on other sites
  • 8 months later...

Sorry for necroing the thread - just a hint for future users experiencing this issue: in my case it was a leftover /volume* folder. Volume1 had existed some time ago in my Synology configuration, but was deleted a while back. However for some reason the folder /volume1 was still there and occupying quite a bit of space (~500MB) with @syno and other folders / app cache, etc. I deleted the folder, restarted and everything was good. Only package that went missing is the synogear / Diagnostic tool package which appeared to have been installed to volume1.

 

TLDR: check for remnants of old volumes (like /volume1 etc) which are no longer in use, delete the appropriate folder, check your packages afterwards if everything is still there. Ah yes, be sure what you are doing - if you delete the wrong /volume folder you will delete your data 😁

Link to post
Share on other sites

For those who come across this thread, this can be a byproduct of a particular Unix/Linux feature.

 

Filesystems are mounted to specific folders in the directory tree.  In this case, it's whatever /dev/mdx or /dev/mapper device that corresponded to the volume1 array that was mounted to /volume1.  As long as that volume is mounted, all writes within the /volume1 branch of the filesystem go to the array.

 

If the array is unmounted, /volume1 still exists but has no files in it (for obvious reasons).  That does not mean that files cannot be written to the /volume1 location.  If that happens, those files are stored in the root filesystem (which is the DSM OS).

 

When the volume1 array is mounted again, all the files that were written to the root OS are hidden/inaccessible but continue to take up space.

 

In OP's case, this happened somehow, then they deleted the array, and the files were exposed, or something in the system decided volume1 still existed and continued to write files to the location, which started filling up the root filesystem.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.