sudo: unable to write to /var/lib/sudo/ts/admin: No space left on device

Thanks for any assistance or guidance on how to resolve this.

As this seems to be related between trying to optimise my LMS setup but now seems to involve fixing something I've broken within the ReadyNAS OS, I've initially posted there in this thread:

Error on 'Clear library and rescan everything' > database or disk is full

and I'll be bouncing between there and here.

There's space on the NAS itself, over 800GB but it seems I've filled up the OS partition.

Thanks for replying Stephen.

To update, I did a reboot from ssh, logged back in, changed to root and didn't get the error. 

Running df -h again gets:

/dev/md0        4.0G  3.1G  585M  85% /

so a small amount of space reclaimed...

Unrelated aside: why don't I have the option to preformat text like in my original post?

Root isn't "/root", it's just "/".  cd  /

So it looks like I've corrupted the filesystem on the system partition. 

Is this repairable?

btrfs fi show /dev/md0

gives

Label: '758ad464:root'  uuid: f08a0f90-adfd-47e1-a519-189247895ced
	Total devices 1 FS bytes used 1.14GiB
	devid    1 size 4.00GiB used 3.67GiB path /dev/md0

Now if I input

df -h

the results are

Filesystem      Size  Used Avail Use% Mounted on
udev             10M  4.0K   10M   1% /dev
/dev/md0        4.0G  1.3G  2.4G  35% /
tmpfs           491M  4.0K  491M   1% /dev/shm
tmpfs           491M  3.7M  487M   1% /run
tmpfs           246M  4.0M  242M   2% /run/lock
tmpfs           491M     0  491M   0% /sys/fs/cgroup
/dev/md127      2.8T  1.5T  1.4T  52% /data
/dev/md127      2.8T  1.5T  1.4T  52% /apps
/dev/md127      2.8T  1.5T  1.4T  52% /home

so there's more space on /dev/md0 but the LLM is now advising that I run

btrfs check --repair

from Ubuntu that's installed on a USB drive but is it possible to amend the boot order in the BIOS using SSH?

Thanks for any assistance.

I fail to see anything that indicates there is a BTRFS error on /dev/md0.  It's just too full.  As StephenB​ has been telling you, you need to find and delete some of the files that are there, most likely the result of LMS.  If the files are corrupted, then a BTRFS repair isn't going to fix them, but an OS re-install might.  But your OS partition is far too full to try that now.

Standard Linux df on a BTRFS file system is unreliable.  You need to run btrfs filesystem df /.  In particular, you need to pay attention to both the data and metadata usage.  As StephenB​ also told you, you may need to run a balance on the OS partition to reclaim metadata.

I've never used LLM, but it's clearly designed for use on a standard BTRFS-based Linux installation.  I think you should stop listening to it so much.  Booting to a USB system to repair the ReadyNAS file system is really a bad idea.  You should be booting to tech support mode, but I see nothing that indicates you need to do that at this time.

Let me just say that I am extremely appreciative and grateful for the time, thought and engagment that anyone offers on a thread like mine, even if my choices and actions may be a source of frustration to those with vastly more experience in using the CLI and delving deep into OSes.

Know that my use of LLMs like DeepSeek, ChatGPT etc, is, in the main, to ask basic questions about commands that do simple things to avoid clogging up a thread like this and exhausting the patience of those for whom it is second nature, whether be it because it's their job or a long-time computer hobbyist & tinkerer. I am mindful that the informal chatty nature of these LLMs whilst seductive, can offer poor or just plain incorrect 'advice' for the more complicated questions and ideally, s/b run by anyone who is willing and able to read over it in forums like this.

StephenB wrote:

This is normal - did you remove files to bring it down to this level?

Yes. I installed ncdu and found that Syncthing (installed incorrectly in this location to begin with) was taking up 2+GB space, so deleted it all as I'll install it again in a different partition, setup and run an initial sync again, no big deal apart from the time a first sync takes.

Before that, I deleted everything from /var/lib/squeezeboxserver/cache, which was recommended on a help thread I started within the Lyrion (renamed from Logitech) support forums but that only reclaimed a few hundred MBs.

StephenB wrote:

Instead run this (using ssh on the NAS, logged in as root) :

Thanks for the suggestion. I ran it, despite the ominous warning about how long it may take, it took less than a minute, no error messages and the output was:

WARNING:

	Full balance without filters requested. This operation is very
	intense and takes potentially very long. It is recommended to
	use the balance filters to narrow down the scope of balance.
	Use 'btrfs balance start --full-balance' option to skip this
	warning. The operation will start in 10 seconds.
	Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
Done, had to relocate 11 out of 11 chunks

StephenB wrote:

Which is what I see on bothe new discussions and replies. What format options are you looking for????

I just had more options for the initial post that started this thread and expected to be offered the same options for any subsequent post.

I think I was mainly after the Preformatted option as part of the Paragraph dropdown but you don't this for subsequent replies. Anyway, a minor issue that can be worked around, a little jarring but no biggie.

Sandshark wrote:

If the files are corrupted, then a BTRFS repair isn't going to fix them, but an OS re-install might. But your OS partition is far too full to try that now.

OK, I have taken the advice of StephenB​ on board and as I mentioned at the top of this post, have deleted a bunch of files from the LMS cache sub-folder and deleted Syncthing entirely as I shouldn't have installed it on the root partition in the first place (and ignored the nagging warning messages that would pop up sometimes when I logged into the Syncthing GUI, yup my bad).

At time of writing, running df -h gives:

/dev/md0        4.0G  1.4G  2.5G  35% /

Sandshark wrote:

You need to run btrfs filesystem df /.

OK, that gives:

Data, single: total=1.62GiB, used=1.25GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=128.00MiB, used=20.59MiB
GlobalReserve, single: total=16.00MiB, used=0.00B

Are you able to say if that looks ok? Hopefully it does.

I've slightly messed up my LMS, so I'm going to head over to the thread I've posted there because although the LMS rescanned my music library, all the meta data associated with the files disappeared, probably with the deletion of the contents of the cache directory but I'm hoping that the data I need is still within the files in the prefs directory.

I think I need to move the LMS installation from the OS partition too and that could tie in with installing a new stable version of the software that has recently been released (9.0.2) so I could install the LMS correctly in a different location and 🤞 restore all the missing meta data and ratings, assuming I still have the necessary files.

Do you recommend any further actions?

Appreciate your time and replies.

I have installed a couple of packages that aren't Readynas specific that expect to be installed in the root partition, and the following is what I did.  As long as at least most of the files are installed in a separate directory and, more importantly, all data is placed within that directory or another application-specific one, this should work for you.  Note that in specific commands, I've used two spaces as a delimiter to make it clear there is a space.  They aren't necessary, but Linux doesn't care how many spaces you use.

Start by doing a normal install in the OS partition.  Note the name(s) of the new directories created.  I'm using plural here, but it's often just one.  You can run it to make sure it works, but if it creates a database or other large file(s), it's best to not let it do that.  Some time ago, I copied the following command from a Reddit post as a way of finding the newest directory:  find   .   -type d   -printf   '%T@ %p\n'   |  sort  -nr  |  head  -n  1.  Note that the final 1  is the number of directories to list, so you may want to increase it.

Create a mirror (copy all files and folders) of those directories in /apps.  While /apps appears to be at root, it's actually a mountpoint for /data/apps (assuming your main data volume is data).  If there are multiple directories involved, you may want to make your mirrors sub-directories of a main one you create in /apps.

Next, rename the directories in the OS partition and then create symlinks in their place using the original names.

Now, run the program.  If it works, you're almost done.  If it doesn't, go back and see what you missed.  Once it's running as expected, you can delete the renamed directories and you are done.

If the original install has symlinks within it, then there is more work to do changing them, but that will be too application-specific for me to cover here.

Once set up, this will typically also allow you to install updates without having to re-do all this.

So, in a hypothetical install with a single directory (with or without subdirectories):

Normal install creates /usr/local/myapp.

You create /apps/myapp  and copy all contents of /usr/local/myapp there (all in this one command):  cp  -r  /usr/local/myapp   /apps/myapp.

You rename /usr/local/myapp:  mv  /usr/local/myapp  /usr/local/myapp.old.

You create a symlink:  ln  -s  /apps/myapp  /usr/local/myapp.

Test the program.

If all is well, delete the original installation:  rm  -r  /usr/local/myapp.old.

Since you are messing around in the OS partition, double-check all commands before executing.  Writing them in a text file and then pasting from that is a good way to do that.  Plus, you can save the text file for use as a guide for the next install.

I suspect you don't need quite as much detail as I've given, but others who need it may read and try to follow this.