[SOLVED] Mounting network folder to /mnt - System freezes

[ParaDice]

Dear forum,

I'm trying to mount a network folder from a NAS to my system using mount.cifs . Here's the command I use to do that:

Code: Select all

sudo mount.cifs //IP/my/remote/dir /mnt/my/local/dir -o credentials=credentialsfile,rw

This correctly mounts the remote dir to my local machine for a while, which (to my eyes) implies that

• all directories are specified correctly
• the credentials file is accessible and the specified credentials are correct
• the permissions inside the NAS are configured correctly so as to grant access to the user specified in the credentials file

However, after about a minute, cinnamon freezes up and won't respond any more; i can only move the mouse pointer, but that's about it. I can still go to a tty (which I've just used to reboot the machine so far).

The same thing happens, by the way, if I modify /etc/fstab to auto-mount the remote directory. It works for some time, then the system freezes.

Since I'm not sure what kinds of diagnostics I could run to help pinpoint the problem, I was hoping someone could point me to one.

Best wishes,
ParaDice.

[rene]

Does the same thing happen when you mount it to /media/your/local/dir/ rather than /mnt? Not near an 18.x system to check specifically but it'll be a useful debugging step at least: /media is likely to be ignored by, among other things, systemd.

If the same thing DOES happen; never mind...

[ParaDice]

Thanks for the hint! I tried it yesterday (mounted it to /media), but same result: Cinnamon freezes, TTYs 1-6 are still working. What's more:

• If I cd into the mounted location from tty, it shows all the files and folders correctly, so the actual mounting seems to have worked.
• the NAS shows increased disk activity after mount (LEDs flashing, audible disk noise when I'm sitting next to it; I'm the only user at the moment). I've got no idea what's happening there (maybe an indexing process, trying to scan new files from the disk?) and whether it has anything to do with my problem.

[rene]

I expect a thumbnailer is giving you grief; many photo's and/or videos under the mounted locations? You can probably find the culprit by running ps ax or top from the text console when this is happening; also try looking in ~/.xsession-errors. Also: Ctrl-Alt-Esc may in Cinnamon be a faster way of temporarily getting things back up again.

Unfortunately thumbnailers live in the GVFS universe; are hence nearly impossible to configure, certainly not stably so over more than a single version of any distribution. Mounting to /media instead of /mnt stood some change of magically working in that respect; on 17.3 I'm seemingly allowed some form of control through dconf; you can install dconf-editor and see if there's still an org.gnome.desktop.thumbnailers.disable-all setting available. If not: do you have (the package) ffmpegthumbnailer installed? If so, may want to see if removing it helps any.

There's also in Nemo (the file-manager) an Edit -> Preferences -> Preview tab available where you can set previews to never or local files only. May also do something...

[ParaDice]

Dear rene,
thanks for pointing out the thumbnailer as the suspect. It's true, there are lots of image and video files in the mounted folders, so the system might start to thumbnail them.

Most of my efforts to stop it following your tips have failed, though:

• org.gnome.desktop.thumbnailers.disable-all is available in dconf-editor (I'm running LM 18.3), but setting it to true doesn't resolve the problem.
• ffmpeginstaller is not installed.
• Nemo was already configured not to show previews of remote files and folders.
• Ctrl+Alt+Esc does not work to get Cinnamon up and running again - reboot is my only option for now

What did show up in the diagnostics was:

• ~/.xsession-errors.old contains the following entry:

  Code: Select all

  (cinnamon:1708): Cjs-WARNING **: JS ERROR: GLib.Error g-vfs-error-quark: Cache invalid, retry (internally handled)

  Since there is no log time given, I can't tell when this error occured and whether it is related to my mounting efforts.
• While Cinnamon was frozen, I ran htop from the TTY and got this twice at or near the top of my process list:

  Code: Select all

  /usr/lib/gvfs/gvfsd-trash --spawner :1.17 /org/gtk/gvfs/exec_spaw/0
  cinnamon --replace
  

  Added up, these processes use only 25% of my CPU and 10% of my memory, which should hardly be enough to make Cinnamon freeze.

I have attached my htop output in case that's any help.

[rene]

Most of my efforts to stop it following your tips have failed, though

Quite unsurprised; GVFS is a disaster generally, and an unmitigated one wrt. both configuration and debugging. I could get you one heck of a rant concerning that... but let's not for now, since...

[*] While Cinnamon was frozen, I ran htop from the TTY and got this twice at or near the top of my process list:

Code: Select all

/usr/lib/gvfs/gvfsd-trash --spawner :1.17 /org/gtk/gvfs/exec_spaw/0
cinnamon --replace

... we may have an opportunity to fix things first: this seems to point to the Trash component of GVFS, not a thumbnailer. Do you have a particularly large .Trash-0 folder inside of the root of the mounted filesystems? Note the leading period: it/they would be hidden from normal view; in Nemo you use Ctrl-H to show hidden files, from the terminal ls -a would.

Even if they're not large some may be damaged. You are mounting as root so are primarily looking for .Trash-0 folders it seems; I don't believe other Trash-$(id -u) folders should be involved but if there's no .Trash-0 folders but .Trash-1000 folders, say, also be suspicious of those. You mounting as root also means you won't be able to empty them by "Empty Trash" as your regular user: you can probably open a Nemo window "as root" and do it from there but if you're sure there's nothing in the Trash on a particular filesystem that you may still want to retrieve, sudo rm -rf /mnt/your/local/dir/.Trash-* certainly empties it. The folders are automatically recreated when needed.

Added up, these processes use only 25% of my CPU and 10% of my memory, which should hardly be enough to make Cinnamon freeze.

Perhaps not, but add in GVFS and CIFS and it wouldn't surprise me in the slightest in the "Death from I/O" sense. That would've been part of the rant...

[EDIT] Throwing away, commenting out the Exec= line of, or changing the "AutoMount=True" to "AutoMount=false" in, the file /usr/share/gvfs/mounts/trash.mount (the path in 17.3; may differ in 18) and rebooting may also be useful. This would of course have an effect on all of GVFS' Trash handling; you may not want to do so. Rare enough to seemingly have found a bit of GVFS configuration to still warrant an [EDIT] though.

[ParaDice]

Dear rene,

thank you ever so much for your continued support and efforts! That last hint actually did the trick!

It was like you said: The mounted folder had a large trash folder, containing about 6500 files, amounting to ~300MB of space. After deleting this folder, I can now mount the remote folder to my system without any problems.

A note to any QNAP NAS owner reading this: I was under the impression that the QNAP puts everything I delete in what it calls the "network bin" - a trash-like folder that sits inside every top-level directory. Apparently, this is not the case: only files deleted through the QNAP "File" app in your browser interface are put in this "network bin". If you access your QNAP through a typical file explorer, such as nemo, it will create the typical (hidden) .Trash folder. This folder will not be emptied along with the network bin, but must be emptied manually.

As for your GVFS rants, rene: I will join you in your ranting whenever possible now! A file system should not be able to freeze a system, just because of 300MBs of unemptied trash.

Thanks again
and best wishes,
ParaDice.

[rene]

A file system should not be able to freeze a system, just because of 300MBs of unemptied trash.

Quite agree --- although admittedly the Linux kernel itself may need to be assigned blame here as well: you were "kernel mounting" (that is, not through fuse) and although this was a particularly bad case of GVFS on CIFS the kernel should never allow things to come to a point where you feel you need to reboot. There's likely some tuneables here, but CIFS should already be setting sane rsize/wsize defaults these days, and it's not like it's hard to bring a Linux desktop to its knees through I/O with or without GVFS and/or CIFS involved. A USB stick tends to do fine already. As does swapping. And...

But oh well. Good that it's sorted.