48

Does anyone knows why have I this message with the new update of samba on ubuntu 16.04.1?

Paramétrage de samba (2:4.3.9+dfsg-0ubuntu0.16.04.3) ...
Failed to add /run/systemd/ask-password to directory watch: No space left on device: 

Since I have so much space, I don't understand :

df -h
Sys. de fichiers                  Taille Utilisé Dispo Uti% Monté sur
udev                                 16G       0   16G   0% /dev
tmpfs                               3,2G     11M  3,2G   1% /run
/dev/sda2                           107G     49G   53G  48% /
tmpfs                                16G    184K   16G   1% /dev/shm
tmpfs                               5,0M    4,0K  5,0M   1% /run/lock
tmpfs                                16G       0   16G   0% /sys/fs/cgroup
/dev/sdi2                           367G    343G  5,2G  99% /media/divers
/dev/sda1                           110G    366M  104G   1% /opt
/dev/sdm1                           147G    136G   11G  93% /media/nfsmedia/syno/usb4
/dev/sdq1                            74G     69G  1,1G  99% /media/nfsmedia/syno/usb8
/dev/sdp1                           459G    453G  5,6G  99% /media/nfsmedia/syno/usb1
/dev/sde2                           735G    684G   14G  99% /media/series
/dev/sdo1                           1,8T   1015G  726G  59% /media/nfsmedia/syno/usb3
/dev/sdr1                            74G     68G  1,6G  98% /media/nfsmedia/syno/usb7
/dev/mapper/RAIDSTOCK-RAID5FSTOCK   9,0T    7,3T  1,4T  85% /media/RAIDFORSTOCK
/dev/mapper/RAID1FORDOCK-DOCK       550G    303G  220G  58% /media/DOCK
cgmfs                               100K       0  100K   0% /run/cgmanager/fs
tmpfs                               3,2G       0  3,2G   0% /run/user/1004
//192.168.6.12/vigilian             1,9T    1,7T  179G  91% /media/smbseries/nsa
//192.168.6.11/NASA                 930G    807G  123G  87% /media/smbseries/nasa
tmpfs                               3,2G     12K  3,2G   1% /run/user/123
tmpfs                               3,2G       0  3,2G   0% /run/user/1000

2 Answers 2

107

As discussed in a Red Hat bug report, it turns out that the Crashplan back-up service is the most likely culprit. It uses many inotify watches and, eventually, eats them all up.

The immediate fix is to run:

sudo -i
echo 1048576 > /proc/sys/fs/inotify/max_user_watches
exit

to make more watches available.

The long-term fix is to edit the file /etc/sysctl.conf to include the line:

fs.inotify.max_user_watches=1048576
5
  • yes, I've seen it but it wasn't that since I don't have anything like it installed. It seems that iwas samba related or RAID related
    – vigilian
    Oct 30, 2016 at 12:14
  • 15
    This helped me, I have Crashplan
    – Brian Low
    Nov 19, 2016 at 22:29
  • but anyway it stills works. So be aware that it would be a similar problem with too much mdadm notification or smaba notification.
    – vigilian
    Jul 29, 2017 at 23:16
  • Helped me on kali linux
    – Tim Jonas
    Nov 21, 2017 at 11:12
  • 3
    You have to run sysctl -p to reload sysctl.conf right?
    – Jeppe
    Apr 20, 2020 at 6:58
16

I'm not reputable enough to comment on the accepted answer, but I wanted to say that it's by no means limited to CrashPlan. Dropbox and other file sharing platforms use inotify watches per inode to detect when an upstream sync needs to occur. Malware detectors may have watches on directories. Other backup tools besides CrashPlan might, as well.

To see what's consuming inotify watches, use lsof:

sudo lsof -K | grep inotify | (less||more||pg)
1
  • 1
    Absolutely true. No one application can be truly to blame for consumption of inotify watches, and Ubuntu's default is terribly small
    – Auspex
    Jan 6, 2021 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .