timrowledge
Posts: 1327
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Buster CIFS fstab problems

Wed Mar 25, 2020 8:51 pm

I have three machines involved in a circle of CIFS confusion that is driving me nuts. Pointers to doc, advice on settings, commiseratory chocolate all gratefully received.

tl;dr - Buster CIFS fstab mouting seems to be borked

Machine A - an iMac running Mac OS Mojave. On this I have (duh) a lot of files, including some recently cloned from a github repository. This last part is important in the story.
Machine B - a Pi 3 running Raspbian Stretch, which connects to the iMac filesystem perfectly.
Macinhe C - a Pi 3 running Buster that does nto connect to the Mac at all well.

The Stretch Pi has been connecting to the iMac happily for ages, as have many other Pi through the years and Raspbian versions. It has a relatively simple fstab line

Code: Select all

//192.168.1.65/tim /home/pi/DizietFS cifs username=tim,password=XXXXXXX,uid=1000,gid=pi,iocharset=utf8,nounix,sec=ntlmssp,x-systemd.automount 0 0
I can compile code stored on the Mac and write the resultant executables to the Mac and copy the directories with the executables to the local storage with no problems. Excellent! That's how I did all that Scratch development work.

The Buster Pi is being a nuisance. It is updated and upgraded as of last night.

I started with the same fstab line, as one would. When I went to try a compile with code freshly fetched from github things went weird; a couple of tools simply couldn't read the remote files, whereas others could. Geany would read the source but Mousepad couldn't. I tried another project's github clone just in case but it had the same issues. The important thing that is *really* wierd is that almost all files and directories could still be read, moved, edited etc - it was just new ones that caused problems. I created some fresh files not in the github cloned directories in case the directory permissions were strange; no difference, the new files could not be ready by MousePad but could by geany and Squeak etc.

I did a great deal of googling for doc. Not a lot of it made much sense but I did discover that adding '_netdev,vers=1.0,' to the above fstab line meant that mousepad (and the problematic compilation process) could now read the files in the github download and indeed some other recently created files. Yay! I though, problem solved.

Hah, life is, as usual, messing with me. Although I could now compile the code from the iMac hosted directory (which of course involves creating many new files on the iMac as thre object files are produced etc) I could not copy the directory from the iMac to the Pi in order to install the program; the file copy dialogue opens and simply sits there. Eventually I tried a commandline copy of the directory - which worked! So yeah, I can install my stuff but this implies a fairly bad problem somewhere.

I have tried a large number of combinations of options and switches as advised by many web pages. Most recently I have got to -

Code: Select all

//192.168.1.65/tim /home/pi/DizietFS cifs _netdev,vers=3.0,noserverino,noperm,file_mode=0664,dir_mode=0775,username=tim,password=XXXXXX,uid=1000,gid=pi,iocharset=utf8,x-systemd.automount 0 0
The 'noserverino' is there as a direct response to dmesg output that explicity said to try it. The 'noperm' was supposed to avoid permissions issues but doens't appear to do anything helpful.Currently dmesg shows some errors that I haven't been able to find much about with googling -

Code: Select all

[   60.565795] CIFS VFS: SMB signature verification returned error = -5
To add to the soup I have tried completely removing the fstab mounting and instead connected via the filer window 'network' interface, resulting in having pathnames like smb://diziet.local/tim on diziet.local/Documents/Squeak/opensmalltalk-vm. This is interestingly different but still not properly functional. I can copy files and directories - yay! - but the file permissions get messed up. MousePad can read the files on the iMac within the github download. I also tried connecting via the sftp connection offered by the filer, with the same results - mostly good but file permissions screwed. And of course, the whole point of the fstab stuff is to connect automatically, so I'd quite like for it to work as well as it has done for the last several years.

Haaaaaallp!
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

swampdog
Posts: 335
Joined: Fri Dec 04, 2015 11:22 am

Re: Buster CIFS fstab problems

Thu Mar 26, 2020 8:25 pm

iMac is old. So is my samba server. Try downgrading the version. From the command line this (buster) pi can log in..

Code: Select all

[email protected]:~ $ sudo mount -t cifs -o credentials=/home/foo/.smbcred,gid=1000,uid=1000,vers=1.0 //smb/Administrator /mnt/tmp
..and has full access.

Code: Select all

[email protected]:~ $ cat .smbcred 
username=Administrator
password=your_password_here
Adjust uid/gid to taste. My ancient samba also has other credentials such as user "smb" which has read-only permissions on //smb/READONLY and //smb/Administrator but full access to //smb/PUBLIC whereas "Administator" has full access to //smb/READONLY (and the rest). That's all done the samba side.

timrowledge
Posts: 1327
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Buster CIFS fstab problems

Fri Mar 27, 2020 3:35 am

Not entirely sure what you mean by “iMac is old” but it seems to happily support Vers =1.0, 2.0 or 3.0 - only 3.11 raises a complaint.
One of the things that causes much confusion is how the behaviour seems to differ between cmdline mount and fstab lines. And the seemingly wide variations of the content of man pages I find.
I promise, I have tried my local equivalent of your suggestion and had no luck. Meanwhile the Pi with old Stretch sits there smirkingly able to connect...
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Return to “Raspbian”