Mounting CIFS share on Ubuntu

[Jinder]

Hi

I had to rebuild my ubuntu box and previously I was using fstab for mounting my NAS CIFS enabled shares. My fstab looks like this:

//192.168.1.65/Documents /home/jinder/Documents cifs credentials=/home/jinder/.smbcredentials,uid=1000,gid=1000,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

I have a /home/jinder/Documents directory, the share exists and the credentials file has in it my user/pass. The share mounts I can read the files as normal, they are all owned by 'jinder'.. I can do a

touch <filename>

and it gets created normally. But if I do an actual copy of a file or mkdir on the share I get this:

mkdir: cannot create directory `e': No space left on device

if I do this

df -k :

Filesystem            1K-blocks      Used Available Use% Mounted on
//192.168.1.65/media 1457032640 838296512 618736128  58% /home/jinder/media

I can ssh onto my NAS and there is lots of space and I can create files etc. I am running 4.1.10 and I have a ReadyNAS Duo..

So puzzled as to what is going on... I've restarted my NAS no change. In addition I have an external USB drive plugged into my NAS which i can also mount on my Ubuntu machine and copy files to it normally.

Any ideas/suggestions, i'd be very grateful.

[mdgm-ntgr]

On the NAS itself what's the output of

# df -i
# df -h

[Jinder]

At work so I can't get you the exact result.. Although I did try this yesterday, and the Inodes were around 1% and there was plenty of space with the df -h too..

I can create files/directories when I am ssh'd on to the NAS, but then again I am logged on as root.

Whilst looking for a solution I saw some other problems others were reporting that seemed to be similar with shared guest mode, although it was around midnight and the brain wasn't really accepting new ideas at this point. If this is an issue with 4.1.10.. maybe a downgrade to 4.1.9? I have a feeling that it was around the time of the upgrade I started noticing these issues.. infact. I might be able to confirm by looking at the NAS logs to confirm.

[Jinder]

here's the result

Jinders_NAS:/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hdc1 1.9G 739M 1.2G 38% /
tmpfs 16k 0 16k 0% /USB
/dev/c/c 1.4T 800G 590G 58% /c
/dev/sda 2.2T 708G 1.4T 33% /USB/USB_HDD_3
Jinders_NAS:/# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/hdc1 128000 10712 117288 9% /
tmpfs 7073 2 7071 1% /USB
/dev/c/c 45744128 150294 45593834 1% /c
/dev/sda 152625152 123351 152501801 1% /USB/USB_HDD_3

[mdgm-ntgr]

Ah, can you try resetting permission on the share using the Advanced Options tab. See Overview of ReadyNAS Permissions

[Jinder]

Sorry I got it working and thought nothing more of it.. but it's back! So strange.. so.. how I got it working.. I downgraded, 4.1.09. made no difference.

Then I upgraded to 4.1.10.. and it's working fine.. I have the same permissions as before can create dir etc... now a few weeks later.. i've not changed a thing and it's doing the same thing again.

It's obviously possessed!

[SurplusGadgets]

Hope this little tutorial helps. Confusing but key to remember is there are a minimum of four different user accounts to keep straight when analyzing the connection of a Ubuntu Linux box to a ReadyNAS via the CIFS protocol:
[1] The account/group a user is logged into your Ubuntu Linux box with when trying to access the mounted share,
[2] The account/group used by the Ubuntu kernel to interact with the mounted ReadyNAS share,
[3] The account(/group) used by the Ubuntu kernel to connect with the ReadyNAS box, and finally
[4] The account/group setup on your ReadyNAS share that owns the share and sets permissions of objects created in it.
You setup the Ubuntu kernel with the mount.cifs command (or /etc/fstab settings).

The username/password supplied to the Ubuntu mount.cifs command is #3 above: a username/password account on the ReadyNAS to connect or login with.
The UID, GID and Masks supplied to the Ubuntu mount.cifs command are #2 above and from accounts on the Ubuntu machine side.
So use a ReadyNAS account for #3 that will have the appropriate access to the ReadyNAS share as setup on the ReadyNAS under the CIFS setup (#4). Does not need to be the owner (#4) but likely must have the Unix Group access you want.

If you forgo the UID/GID/Mask in the mount.cifs command, you simply see ReadyNAS Linux internal ID's and masks on the Ubuntu side. Similarly, the ReadyNAS Share uses #3 to determine if access is allowed and then #4 to actually manipulate changes to the share. The values used on the Ubuntu box (#1, #2) are ignored.

For me, I use common groups and group RWX access when setting up accounts #1 and #2. And then common groups with group RWX when setting up accounts #3 and #4. You can make #3 default to #1 on Ubuntu by dropping settings in the mount.cifs command, but then you have to replicate the passwd/shadow files on each Ubuntu box on the ReadyNAS (including same ID's).

All this complication comes from the fact that one is using a Windows protocol (CIFS/SMB) to communicate between two Linux systems. ReadyNAS, even in their CIFS setup, is exporting their Linux internal implementation (of owners, groups, and world access; RWX; etc.). Windows and CIFS/SMB uses Users, Domains, and ACL lists.

Am currently struggling to set things up simplest and least error prone myself. Have not dropped back to a setup of CIFS exclusively for Windows, NFS exclusively for Linux, and only streaming protocols for the Android devices -- as this still requires keeping common accounts kept up to date. Have not found a nice tutorial on how to do a setup close to what I want yet either ...

Oh, and I have a 16TB Ultra4+ and 8TB NV4+. The former gotten after discovering no more firmware upgrades to allow expansion of the NV+ 😞 But key is there are multiple ReadyNAS to keep up to date with account settings as well.

A few final things that I learned the hard way. Use settings in your /etc/fstab entries of noauto, users, and _netdev. You can get into issues when the Ubuntu box boots otherwise. And remember /etc/fstab is visible to everyone. So if you want the #2 account password hidden, use a "credentials" setting with a file that is protected from all but root. (But then you cannot allow a user to auto-mount and dismount shares easily either.) Still fine tuning ....

Here is an example of my /etc/fstab entries:

//MediaServer.local/MoviesMP4 /media/MoviesMP4 cifs noauto,users,_netdev,credentials=/root/.smbcredentials,iocharset=utf8,uid=randy,gid=users,file_mode=0774,dir_mode=0775 0 0

[Jinder]

Many thanks for responding and the excellent explanation.. however I still have the same issue.. quick summary

I have a share called /Documents, it's setup for CIFS and the default access in Frontview is read/write access, and Automatically set permissions on new files and folders is set to true.

my user on the readynas is Jinder who is UID of 1004 and he is a member of users (GID 100)

this is what I have in fstab

//192.168.1.65/Documents /home/jinder/Documents cifs noauto,users,_netdev,credentials=/home/jinder/.smbcredentials,iocharset=utf8,uid=1004,gid=100,file_mode=0774,dir_mode=0775 0 0

in the credentials I have my user/password for the user Jinder on the readynas

I can create files so if I do a

'touch j'

that's fine I can also do a

'rm j'

no problem.. but if I do a

'mkdir k'

then I get a

'mkdir: cannot create directory `k': No space left on device'

'df -k .' shows

Filesystem 1K-blocks Used Available Use% Mounted on
//192.168.1.65/Documents 1457032640 871754528 585278112 60% /home/jinder/Documents

This is SO odd.. why can I do somethings but not others? Incidently my ubuntu user is jinder:jinder

any other things you can think of that I can do to bottom this out?