I’ve encountered a really strange issue while mouting a SMB share on my Synology today. I started to mount the remote share using the following command:
root@nas:/# mount -t cifs -o username=user,password=pass //ip/share/ /mnt
and I was able to list the first directory level in the tree (inside /mnt), but I encountered this really weird error while trying to list anything deeper in the directory structure (/mnt/dir1).
root@nas:/mnt/dir1# ls ls: reading directory .: Not a directory
Weird right ?
I ended up finding this option inside the
cifs.mount man page:
nounix; disable the CIFS Unix Extensions for this mount. This can be useful in order to turn off multiple settings at once. This includes POSIX acls, POSIX locks, POSIX paths, symlink support and retrieving uids/gids/mode from the server. This can also be useful to work around a bug in a server that supports Unix Extensions. See section INODE NUMBERS for more information.
that refers to:
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.
so not sure of what triggers this error if it’s linked to these POSIX calls and inode number or if it’s a bug in the SMB stack on my NAS that is bypassed using this option. Passing it as a mount option solved my issue. I also checked that all the files attributes where correct (read/access times, permissions, …) and they were.
root@nas:/# mount -t cifs -o username=user,password=pass,nounix //ip/share/ /mnt
Comments are welcome.