File Browser does not show subdirectories

I am not able to list from sonarr subdirectories of a cifs share.

Platform: Vero4K (armhf)
OS: OSMC (Debian 8)
Mono 4.8
Sonar 2.0.0.4645

Steps to reproduce:

  • Mount a cifs share:

> sudo mount -t cifs -o credentials=/etc/samba/tcdisk.cred,uid=osmc,gid=osmc //10.8.1.2/TC-Disk/Videos/Movies /mnt/tcdisk/videos2

  • Test read & write
> mkdir /mnt/tcdisk/videos2/test
> ls -l /mnt/tcdisk/videos2/
drwxr-xr-x 2 osmc osmc 0 mar 18 01:32 test
  • Run Sonarr

> mono --debug NzbDrone.exe

  • On Sonarr web, Series -> Add Series -> Import Existing Series on Disk -> Navigate to /mnt/tcdisk/videos2/

Result empty
…
Expecting the test directory.
Debug logs enabled, but no errors or other helpful info there.

Other applications working (Sickrage, Couchpotato …).

Any help?

Have you taken a look at other recent threads about cifs shares?

https://forums.sonarr.tv/search?q=cifs%20share%20order%3Alatest

I have. Generally dealing with write permissions problem, but nothing solved dealing with no being able to browse to a location.

Did some tests and posted over at mono for help:

http://mono.1490590.n4.nabble.com/Accessing-shared-file-system-td4670282.html

I wonder if downgrading mono might help since you’re seeing this fail in your test app as well.

Well I tried both Mono 4.8 and Mono 3.2.8. On Mono IRC someone ran the test and could not reproduce. Might be platform specific.

Ahh very well could be, we’ve seen our share of those unfortunately.

I’ve found that it’s much better to import by going to WANTED > Manual Import.

I am also using CIFS shares. My issues was different than yours, though. It just simply couldn’t tag or identify most of the content. (However, it identifies it correct 99% of the time through the WANTED > Manual Import.)

I think the problem here is it’s not showing anything to Sonarr (which does seem to be a platform issue when I looked at the thread linked above). Manual import uses the same file browser to find the folder and isn’t useful if you can’t add the series because Sonarr can’t see the contents.

Is it an XFS filesystem by any chance? either where you mounted it or remotely.

Hello

I now know the source of my problems. They are in relation with the particularities of the platform that I am running, which mixes a 64 bit arm64 kernel with a 32 bit armhf userland, and the fact that mono armhf was not compiled with large filesystem support.

Among the options I had was to use mono arm64 (but id id not like the 64 bit dependencies it would bring to my 32 bit userland) and recompile mono armhf with large file system support. As I was working on this last option, I found an easier way out. From mount.cifs man page:

Inode Numbers

When Unix Extensions are enabled, we use the actual inode number provided by the server in response to the POSIX calls as an inode number.

When Unix Extensions are disabled and “serverino” mount option is enabled there is no way to get the server inode number. The client typically maps the server-assigned “UniqueID” onto an inode number.

Note that the UniqueID is a different value from the server inode number. The UniqueID value is unique over the scope of the entire server and is often greater than 2 power 32. This value often makes programs that are not compiled with LFS (Large File Support), to trigger a glibc EOVERFLOW error as this won’t fit in the target structure field. It is strongly recommended to compile your programs with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this problem. You can also use “noserverino” mount option to generate inode numbers smaller than 2 power 32 on the client. But you may not be able to detect hardlinks properly.

Are there any problems with Sonarr and XFS?

Yes, compiling mono with the same switch should resolve it.

Markus, I plan to move my entire library from ext4 to ZFS in about 2 weeks. Just waiting for new drives to ship so I can setup a raidz1. I’m running ubuntu 16.10 x64. I’m not compiling anything, just using apt-get to install various packages.

I had found this page for copying hard links when I transfer my data: https://www.cyberciti.biz/faq/linux-unix-apple-osx-bsd-rsync-copy-hard-links/#comment-911436

Is there anything else I should know before I attempt to do this with the way ZFS works? Should I be compiling mono manually? Etc.

That’s exactly why I mentioned XFS, coz it has 64bit inodes and any filesystem entry with an inode that’s larger than 4294967295 won’t be visible to the 32bit mono.

james@rocinante:~$ mono --version
Mono JIT compiler version 4.2.1 (Debian 4.2.1.102+dfsg2-7ubuntu4)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen

So I should be fine with this?

What do you think?

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.