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
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.
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
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 -
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
//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
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.
Code: Select all
[ 60.565795] CIFS VFS: SMB signature verification returned error = -5