# Odd CIFS issue (fixed-ish)

## Bigun

So, I mount a samba share using CIFS, it mounts and works fine for a while.  Then after about a day it seizes up.

Any amount of troubleshooting usually locks up the terminal, and I'm forced to push the reset button on the server.

When I try to unmount the share:

```
 # /etc/init.d/netmount stop

 * Unmounting network filesystems ...
```

or

```
# umount /mnt/external_storage
```

It outputs nothing.

dmesg catches a little bit of what's going on:

```
[189406.826593] CIFS VFS: Autodisabling the use of server inode numbers on \\127.0.0.1\Media.

[189406.826596] CIFS VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS).

[189406.826597] CIFS VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.

[189593.442253] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[189779.810254] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[189966.178264] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[190152.546206] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[190338.914245] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[190525.282259] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[190711.650227] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[190898.018223] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[191084.386239] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[191270.754153] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[191457.122227] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[191643.490220] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[191829.858218] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192016.226202] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192202.594207] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192388.962122] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192575.330197] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192761.698191] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[192948.066125] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[193134.434180] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[193320.802178] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[193507.170165] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[193693.538176] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[193879.906163] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[194066.274157] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[194252.642090] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...

[194439.010149] CIFS VFS: \\127.0.0.1 has not responded in 180 seconds. Reconnecting...
```

Yes, I know I'm mounting a samba share on the exact server that's hosting it.  There's method to that madness, but that is another story.

This setup was working fine for a *LONG* (literally years) time, I suspect the culprit to be the new kernel, I think things started to break when I upgraded:

```
[ebuild   R    ] sys-kernel/gentoo-sources-5.4.28:5.4.28::gentoo  USE="-build -experimental -symlink" 0 KiB
```

----------

## Hu

 *Bigun wrote:*   

> Any amount of troubleshooting usually locks up the terminal, and I'm forced to push the reset button on the server.

 Does a lazy unmount work?  This can succeed even if the server is broken. *Bigun wrote:*   

> Yes, I know I'm mounting a samba share on the exact server that's hosting it.  There's method to that madness, but that is another story.

 Perhaps you should fix this by not doing something mad.  What are you trying to achieve that this is the solution you chose? *Bigun wrote:*   

> This setup was working fine for a *LONG* (literally years) time, I suspect the culprit to be the new kernel, I think things started to break when I upgraded:
> 
> ```
> [ebuild   R    ] sys-kernel/gentoo-sources-5.4.28:5.4.28::gentoo  USE="-build -experimental -symlink" 0 KiB
> ```
> ...

 Kernel 5.6.8 is out.  If you suspect a kernel regression, then please try a newer kernel to see if it has already been fixed.

Have you checked whether the problem is that Samba has deadlocked itself trying to access its own mount?

----------

## Bigun

 *Hu wrote:*   

> Does a lazy unmount work?  This can succeed even if the server is broken.

 

This did work, I was able to unmount the share.

 *Hu wrote:*   

> Perhaps you should fix this by not doing something mad.  What are you trying to achieve that this is the solution you chose?

 

That's another rabbit trail I prefer not to go into right just now.  I'll shorten the story to this:  I needed a program to access data on a mount as if it was accessing in through a samba share on the local machine.

 *Hu wrote:*   

> Kernel 5.6.8 is out.  If you suspect a kernel regression, then please try a newer kernel to see if it has already been fixed.

 

Emerging and building now, will report back.

 *Hu wrote:*   

> Have you checked whether the problem is that Samba has deadlocked itself trying to access its own mount?

 

Yeah, even after I unmount the share, samba is deadlocked:

```
projector /home/bigun # /etc/init.d/samba stop

 * WARNING: samba is already stopped

projector /home/bigun # /etc/init.d/samba start

 * samba -> start: smbd ...

 * start-stop-daemon: /usr/sbin/smbd is already running                                                                                                                                                                                [ !! ]

 * samba -> start: nmbd ...                                                                                                                                                                                                            [ ok ]

 * Error: starting services (see system logs)

 * samba -> stop: smbd ...

 * start-stop-daemon: 3 process(es) refused to stop                                                                                                                                                                                    [ !! ]

 * samba -> stop: nmbd ...                                                                                                                                                                                                             [ ok ]

 * ERROR: samba failed to start

projector /home/bigun # ps -A | grep smbd

21586 ?        00:00:00 smbd

21609 ?        00:00:00 smbd

21637 ?        00:00:00 smbd

projector /home/bigun # kill -9 21586

projector /home/bigun # kill -9 21609

projector /home/bigun # kill -9 21637

projector /home/bigun # ps -A | grep smbd

21586 ?        00:00:00 smbd

21609 ?        00:00:00 smbd

21637 ?        00:00:00 smbd
```

Again, the new kernel may fix this.

----------

## Bigun

Took longer, but it did happen again. 

```
bigun@projector ~ $ uname -a

Linux projector 5.6.10-gentoo #1 SMP Tue May 5 12:10:50 EDT 2020 i686 Intel(R) Celeron(R) CPU G530 @ 2.40GHz GenuineIntel GNU/Linux

```

----------

## Hu

I think you need to stop letting Samba see the mounts that it serves.  That is just asking for trouble, as you have found.  If you cannot stop loopback mounting your own system, at least run Samba in a mount namespace where those mounts are not present.  As I hinted above, I strongly suggest that you stop using this loopback mount scheme at all.

----------

## Bigun

 *Hu wrote:*   

> I think you need to stop letting Samba see the mounts that it serves.  That is just asking for trouble, as you have found.  If you cannot stop loopback mounting your own system, at least run Samba in a mount namespace where those mounts are not present.  As I hinted above, I strongly suggest that you stop using this loopback mount scheme at all.

 

The core issue was this:

https://www.reddit.com/r/PleX/comments/bbgpzg/symbolic_links_not_working_with_plex/

I bit the bullet and after some research the solution was this:

https://engineerworkshop.com/blog/how-to-share-part-of-your-plex-libraries-without-giving-users-complete-access-to-your-full-library-symbolic-links-with-plex-and-docker-containers/

Basically I was using a Samba share mount as a workaround for this weird issue.  Now that I have relative symbolic links deployed, Plex is finally satisfied without a local Samba mount.

----------

## Hu

If you are using a Docker container, you could just have Docker map the relevant files into the container in the right place and avoid messing with symlinks at all.

----------

