Insufficient capacity for update [merged thread]

Topics pertaining to volume setup, boot/shutdown, initialization, DSM update, HDD migration.
Forum rules
We've moved! Head over to Synology Community (community.synology.com) to meet up with our team and other Synology enthusiasts!
User avatar
HarryPotter
Honorary Moderator
Honorary Moderator
Posts: 19674
Joined: Mon Oct 23, 2006 12:48 pm
Location: Switzerland

Re: Insufficient capacity for update [merged thread]

Unread post by HarryPotter » Thu Mar 24, 2016 7:05 pm

And both of you have fully used te available space on volume1. Free some GB and try again.
*Please do not Private Message me for support questions; leave it on the forum so all members can learn. Thanks!*

DS718+ / DSM 6.2-23511 / ST4000VN000-2AH166 / SA400S37120G SSD cache /16 GB RAM
DS415+ / DSM 6.2-23511

LMS 7.9.1-166, 2 Squeezebox 3 + Boom

APC Smart UPS SUA750i

MrReed06
I'm New!
I'm New!
Posts: 2
Joined: Thu Mar 24, 2016 12:18 pm

Re: Insufficient capacity for update [merged thread]

Unread post by MrReed06 » Fri Mar 25, 2016 12:31 am

Mine is serving a single block level iSCSI LUN, decreasing capacity isn't possible, I'd have to nuke and rebuild it to free some space, given what's on it (backups), let's say I'll stay on 5.2 then. What does volume1 have to do with the boot partition anyway?

User avatar
maxxfi
Compiler
Compiler
Posts: 6794
Joined: Sun Dec 27, 2009 12:13 pm
Location: Espoo, Finland

Re: Insufficient capacity for update [merged thread]

Unread post by maxxfi » Fri Mar 25, 2016 8:28 am

MrReed06 wrote:What does volume1 have to do with the boot partition anyway?
Nothing. There is no 'boot' partition, and the system partition is hidden from the User view in the web UI
No longer using Synology NAS, moved to more open source solutions.
DS-106j > DS-210j > DS-411

Kb1ibt
I'm New!
I'm New!
Posts: 1
Joined: Mon Mar 28, 2016 4:14 am

Re: Insufficient capacity for update [merged thread]

Unread post by Kb1ibt » Mon Apr 04, 2016 3:17 pm

MrReed06 wrote:Mine is serving a single block level iSCSI LUN, decreasing capacity isn't possible, I'd have to nuke and rebuild it to free some space, given what's on it (backups), let's say I'll stay on 5.2 then. What does volume1 have to do with the boot partition anyway?
Is there a way for people like us to upgrade to 6 other than completely blowing away the data on the device? I have a RS3614xs+ and it is claiming I need 4.6GB of space but my root filesystem is only 2.3GB in size and 1.5GB is free. That means it is requesting double the capacity of the entire root volume, not just double the free space. I have a volume1 which has 4.6GB free but the majority of my 21.8TB is dedicated to a single iSCSI volume.

It isn't like I can copy the data off, I have over 71TB of deduplicated backups on that iSCSI volume, I don't have that much space just sitting around else where to move the data to.

rschletty
I'm New!
I'm New!
Posts: 5
Joined: Wed Dec 03, 2014 6:23 pm

Re: Insufficient capacity for update [merged thread]

Unread post by rschletty » Thu Apr 07, 2016 8:45 pm

The problem is solved. I deleted a 1.2 GB file called user-error_log from /var/log/httpd (via ssh terminal session as root).

Another user (Patu) reported the same solution: https://forum.synology.com/enu/viewtopi ... ll#p346979

After a complete shutdown and restart of my Synology DS 1513+, 1.2 GB of space became available in my md0 system partition. All is well now. I am running DSM 6.0-7321. The DSM Update module no longer gives the "Insufficient capacity for update" alert.

Another issue solved was something I reported yesterday at this thread:
https://forum.synology.com/enu/viewtopi ... 78#p427878
Personal Options weren't sticking (desktop wallpaper, hello screens kept reappearing at every login, etc.). This was obviously related to the system partition being completely full (could not write personal user prefs to disk).

NOTE: Since I was doing a shutdown, I took the opportunity to install a second 2GB SODIMM (Mushkin brand), as long as I was doing a complete shutdown. I now have 4 GB of memory, but I am sure this was not the reason that half of my system partition became available.

Before:

root@SchlettyFiles:/# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2385528 2267552 0 100% /
none 1018312 4 1018308 1% /dev
/tmp 1022596 580 1022016 1% /tmp
/run 1022596 2700 1019896 1% /run
/dev/shm 1022596 116 1022480 1% /dev/shm
none 4 0 4 0% /sys/fs/cgroup
/dev/vg1000/lv 14516558000 12485907428 2030531788 87% /volume1

After cold restart:

admin@SchlettyFiles:~$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2385528 1022008 1244736 46% /
none 2016980 4 2016976 1% /dev
/tmp 2021264 1056 2020208 1% /tmp
/run 2021264 2488 2018776 1% /run
/dev/shm 2021264 8 2021256 1% /dev/shm
none 4 0 4 0% /sys/fs/cgroup
/dev/vg1000/lv 14516558000 12485310612 2031128604 87% /volume1

go2
Trainee
Trainee
Posts: 19
Joined: Thu Apr 24, 2014 8:52 am

Re: Insufficient capacity for update [merged thread]

Unread post by go2 » Mon Apr 18, 2016 9:39 pm

My problem solved as well thanks to these postings :-) I had added a package at /usr/local/packages and that was taking too much space. I moved it to /volume1 and added a softlink instead, and voilà.... Problem solved.

ITCIPbutmostlyIP
Trainee
Trainee
Posts: 11
Joined: Tue Apr 26, 2016 5:11 pm

Re: Insufficient capacity for update [merged thread]

Unread post by ITCIPbutmostlyIP » Fri Apr 29, 2016 8:53 pm

go2 wrote:My problem solved as well thanks to these postings :-) I had added a package at /usr/local/packages and that was taking too much space. I moved it to /volume1 and added a softlink instead, and voilà.... Problem solved.
Is there a way to check this from the GUI (I'm assuming that you're using SSH)? I'm getting the same error and don't understand since I have 4TB free space.

User avatar
maxxfi
Compiler
Compiler
Posts: 6794
Joined: Sun Dec 27, 2009 12:13 pm
Location: Espoo, Finland

Re: Insufficient capacity for update [merged thread]

Unread post by maxxfi » Fri Apr 29, 2016 11:16 pm

ITCIPbutmostlyIP wrote:
go2 wrote:My problem solved as well thanks to these postings :-) I had added a package at /usr/local/packages and that was taking too much space. I moved it to /volume1 and added a softlink instead, and voilà.... Problem solved.
Is there a way to check this from the GUI (I'm assuming that you're using SSH)? I'm getting the same error and don't understand since I have 4TB free space.
Nope, because from GUI you don't even see the part of the disk that includes /usr/local/packages (which is where the DSM resides).
No longer using Synology NAS, moved to more open source solutions.
DS-106j > DS-210j > DS-411

matteocim79
I'm New!
I'm New!
Posts: 1
Joined: Mon May 02, 2016 4:42 pm

Update DSM versione 6.0-7321 for RS2414rp+

Unread post by matteocim79 » Wed May 04, 2016 12:07 pm

Good morning,
I have this problem, I have two Synology RS2414rp + that require upgrading to DSM 6.0-7321 version. My problem appears when you start the upgrade, both in automatic and manual modes, after a few moments of installation (about 20%), I get the following message:
Insufficient space on the startup disk. Contact Synology's Technical Support.
I tried to find a possible solution in the forum found nothing really concrete, I tried to access the device via putty with the SSH protocol but I do not know what to remove without causing problems to the system.
Thanks for your help
Matteo

Phylum
Student
Student
Posts: 76
Joined: Sat Oct 15, 2011 5:58 pm

[SOLVED] Insufficient capacity for update

Unread post by Phylum » Fri May 06, 2016 5:40 pm

Am running DSM 6.0-7321 Update 3 on a DS411+II and I ran into the
Insufficient capacity for update
error this morning while investigating why CloudSync wasn't synchronizing with the NAS.
After troubleshooting as far as I could (restarting the client app, checking file permissions, rebooting the client system, restarting the service on the NAS etc.) I checked for any udpates and noticed the error.

I ssh'd in and confirmed root was out of space:

Code: Select all

root@NAS:/# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/md0                         2.3G  2.3G     0 100% /
none                             2.0G  4.0K  2.0G   1% /dev
/tmp                             2.0G  1.4M  2.0G   1% /tmp
/run                             2.0G   12M  2.0G   1% /run
/dev/shm                         2.0G  4.0K  2.0G   1% /dev/shm
none                             4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/vg1/volume_1                5.7T  5.6T  131G  98% /volume1
\\remote.f.q.dn\share  3.6T  1.5T  2.2T  42% /volume1/Mounts/Local_Path
Knee-jerk reaction was to look at /var/log where I found, what was likely, the culprit:

Code: Select all

root@NAS:/var/log# du -hsx * | sort -rh | head -n 10
1.4G    pluto.log
72M     cstn
15M     cloudsync
12M     synolog
6.7M    messages
4.4M    upstart
4.3M    kern.log
4.0M    samba
3.8M    scemd.log
3.7M    router.log
I rm'd the file, restarted the NAS and it was happy.

Code: Select all

root@NAS:~# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/md0                         2.3G  961M  1.3G  44% /
none                             2.0G  4.0K  2.0G   1% /dev
/tmp                             2.0G  1.2M  2.0G   1% /tmp
/run                             2.0G  3.3M  2.0G   1% /run
/dev/shm                         2.0G  4.0K  2.0G   1% /dev/shm
none                             4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/vg1/volume_1                5.7T  5.6T  130G  98% /volume1
\\remote.f.q.dn\share  3.6T  1.5T  2.2T  42% /volume1/Mounts/Local_Path
When it came back up, CloudStation started synchronizing again, solving the initial issue, and I was able to update to DSM 6.0-7321 Update 6

So, why was that file so large? Is there no log rotation [for all logs]?


Still, I looked elsewhere to make sure I could account for any large files/directories.

Code: Select all

root@NAS:/# for i in bin config dev etc etc.defaults initrd lib lib32 lib64 lost+found mnt root run sbin sys usr var var.defaults; do du -hsx /$i* | sort -rh | head -n 10; done
0       /bin
0       /config
4.0K    /dev
10M     /etc
8.9M    /etc.defaults
8.9M    /etc.defaults
4.0K    /initrd
0       /lib64
0       /lib32
0       /lib
0       /lib32
0       /lib64
4.0K    /lost+found
4.0K    /mnt
68K     /root
12M     /run
0       /sbin
0       /sys
761M    /usr
158M    /var
5.8M    /var.defaults
5.8M    /var.defaults

root@NAS:/# du -hsx /usr/* | sort -rh | head -n 10
267M    /usr/syno
261M    /usr/lib
70M     /usr/local
67M     /usr/share
65M     /usr/bin
22M     /usr/sbin
12M     /usr/lib32
972K    /usr/libexec
0       /usr/lib64

root@NAS:/# for i in syno lib; do du -hsx /usr/$i/* | sort -rh | head -n 10; done
203M    /usr/syno/synoman
47M     /usr/syno/etc
14M     /usr/syno/locale
5.9M    /usr/syno/bin
5.1M    /usr/syno/sbin
2.3M    /usr/syno/ipsec
2.2M    /usr/syno/etc.defaults
980K    /usr/syno/selfcheck
420K    /usr/syno/synoce
368K    /usr/syno/share
34M     /usr/lib/python2.7
25M     /usr/lib/modules
17M     /usr/lib/samba
14M     /usr/lib/locale
12M     /usr/lib/libavcodec.so.56
9.8M    /usr/lib/synoce
9.1M    /usr/lib/liblucene++.so.3.0.7
6.4M    /usr/lib/php
6.4M    /usr/lib/gconv
6.3M    /usr/lib/firmware

root@NAS:/# du -hsx /usr/syno/synoman/* | sort -rh | head -n 10
121M    /usr/syno/synoman/webman
31M     /usr/syno/synoman/indexdb
18M     /usr/syno/synoman/mobile
12M     /usr/syno/synoman/webapi
8.5M    /usr/syno/synoman/scripts
5.8M    /usr/syno/synoman/synohdpack
3.3M    /usr/syno/synoman/webfm
2.9M    /usr/syno/synoman/sharing
2.1M    /usr/syno/synoman/synoSDSjslib
140K    /usr/syno/synoman/phpsrc

root@NAS:/# du -hsx /usr/syno/synoman/webman/* | sort -rh | head -n 10
63M     /usr/syno/synoman/webman/help
31M     /usr/syno/synoman/webman/modules
17M     /usr/syno/synoman/webman/texts
12M     /usr/syno/synoman/webman/resources
160K    /usr/syno/synoman/webman/desktop.js
44K     /usr/syno/synoman/webman/forget_passwd.cgi
28K     /usr/syno/synoman/webman/login.cgi
28K     /usr/syno/synoman/webman/index.cgi
24K     /usr/syno/synoman/webman/pingpong.cgi
16K     /usr/syno/synoman/webman/security.cgi

For those in the know: If you're seeing room for improvement, let me know as I'd be willing to explore.

ITCIPbutmostlyIP
Trainee
Trainee
Posts: 11
Joined: Tue Apr 26, 2016 5:11 pm

Re: [SOLVED] Insufficient capacity for update

Unread post by ITCIPbutmostlyIP » Sat May 07, 2016 12:45 am

Phylum wrote:Am running DSM 6.0-7321 Update 3 on a DS411+II and I ran into the
Insufficient capacity for update
error this morning while investigating why CloudSync wasn't synchronizing with the NAS.
After troubleshooting as far as I could (restarting the client app, checking file permissions, rebooting the client system, restarting the service on the NAS etc.) I checked for any udpates and noticed the error.

I ssh'd in and confirmed root was out of space:

Code: Select all

root@NAS:/# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/md0                         2.3G  2.3G     0 100% /
none                             2.0G  4.0K  2.0G   1% /dev
/tmp                             2.0G  1.4M  2.0G   1% /tmp
/run                             2.0G   12M  2.0G   1% /run
/dev/shm                         2.0G  4.0K  2.0G   1% /dev/shm
none                             4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/vg1/volume_1                5.7T  5.6T  131G  98% /volume1
\\remote.f.q.dn\share  3.6T  1.5T  2.2T  42% /volume1/Mounts/Local_Path
Knee-jerk reaction was to look at /var/log where I found, what was likely, the culprit:

Code: Select all

root@NAS:/var/log# du -hsx * | sort -rh | head -n 10
1.4G    pluto.log
72M     cstn
15M     cloudsync
12M     synolog
6.7M    messages
4.4M    upstart
4.3M    kern.log
4.0M    samba
3.8M    scemd.log
3.7M    router.log
I rm'd the file, restarted the NAS and it was happy.

Code: Select all

root@NAS:~# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/md0                         2.3G  961M  1.3G  44% /
none                             2.0G  4.0K  2.0G   1% /dev
/tmp                             2.0G  1.2M  2.0G   1% /tmp
/run                             2.0G  3.3M  2.0G   1% /run
/dev/shm                         2.0G  4.0K  2.0G   1% /dev/shm
none                             4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/vg1/volume_1                5.7T  5.6T  130G  98% /volume1
\\remote.f.q.dn\share  3.6T  1.5T  2.2T  42% /volume1/Mounts/Local_Path
I've ventured into SSH and using the above information that Phylum posted, was able to determine that the user-error_log file is 1.5GB. I am hesitant to remove the file since I read on a Linux forum that: "using rm can cause an odd situation where the file doesn't exist in that directory any more but the process still has it open and is writing to it. You won't have freed up any disk space and you won't be able to get to the logs that are being written." While I'm happy that removing the file will address the "insufficient space" issue, I don't want to create another problem down the road. I also read that I could use "logrotate" but I'm still not sure if there will be any issues --- Anyone tried it? Thoughts?

User avatar
maxxfi
Compiler
Compiler
Posts: 6794
Joined: Sun Dec 27, 2009 12:13 pm
Location: Espoo, Finland

Re: [SOLVED] Insufficient capacity for update

Unread post by maxxfi » Sat May 07, 2016 6:18 am

ITCIPbutmostlyIP wrote: I've ventured into SSH and using the above information that Phylum posted, was able to determine that the user-error_log file is 1.5GB. I am hesitant to remove the file since I read on a Linux forum that: "using rm can cause an odd situation where the file doesn't exist in that directory any more but the process still has it open and is writing to it. ...
That is true, in some cases it be a problem.
The simple solution is, instead of doing "rm filename" you can do "cat /dev/zero > filename". That would effectively truncate the file to zero bytes and it won't affect any process that has a file descriptor still open on that file.
No longer using Synology NAS, moved to more open source solutions.
DS-106j > DS-210j > DS-411

ITCIPbutmostlyIP
Trainee
Trainee
Posts: 11
Joined: Tue Apr 26, 2016 5:11 pm

Re: [SOLVED] Insufficient capacity for update

Unread post by ITCIPbutmostlyIP » Sat May 07, 2016 2:18 pm

maxxfi wrote: That is true, in some cases it be a problem.
The simple solution is, instead of doing "rm filename" you can do "cat /dev/zero > filename". That would effectively truncate the file to zero bytes and it won't affect any process that has a file descriptor still open on that file.
I ran the following and my file size increased and didn't let me truncate it:

Code: Select all

root@DiskStation:/var/log/httpd# du -hsx *
24K     sys-cgi_log
116K    sys-error_log
48K     user-error_log
1.4G    user-error_log.1
24K     user-error_log.1.xz
root@DiskStation:/var/log/httpd# cat /dev/zero > user-error_log.1
cat: write error: No space left on device
The the file increased:

Code: Select all

root@DiskStation:/var/log/httpd# du -hsx *
24K     sys-cgi_log
116K    sys-error_log
48K     user-error_log
1.6G    user-error_log.1
24K     user-error_log.1.xz
I couldn't find a straight answer on the Linux forums about how to deal with the "No Space left on device" error other than what seems to be the obvious -- remove some files. I'm hesitant to just remove files and the solution that Maxxfi provide seems reasonable. While I don't want to turn this thread into a Linux training session, I think it's important to mention it here and pursue a resolution for other folks like myself that are experiencing this in their Synology NAS and are also new to Linux.

I appreciate the responses and guidance.

ITCIPbutmostlyIP
Trainee
Trainee
Posts: 11
Joined: Tue Apr 26, 2016 5:11 pm

Re: Insufficient capacity for update [merged thread]

Unread post by ITCIPbutmostlyIP » Sat May 07, 2016 2:31 pm

I ran the command again and the issue has been solved!

Thanks to everyone that contributed! I hope that the new update fixes my sluggish performance and SS issues.

jduehmig
I'm New!
I'm New!
Posts: 1
Joined: Wed May 11, 2016 3:11 pm

DS412+ available boot disk space is insufficient

Unread post by jduehmig » Wed May 11, 2016 3:16 pm

I have the seemingly common error that I am unable to apply the available update due to the error "available boot disk space is insufficient". However, I have connected to the system via SSH and it does not appear that I have a space problem at the root. Can someone tell me what my options are?
thanks,
Joe

DiskStation> df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.3G 690M 1.5G 32% /
/tmp 495M 132K 495M 1% /tmp
/run 495M 2.2M 493M 1% /run
/dev/shm 495M 0 495M 0% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
/dev/bus/usb 491M 4.0K 491M 1% /proc/bus/usb
/dev/vg1000/lv 8.2T 8.2T 664M 100% /volume1
DiskStation>

Locked

Return to “Installation, Configuration, Migration, Expansion”