CIFS mount inside Shared folder

[ferropop]

Hi quick question!

I have enabled the "Shared" folder in MiniMig.
I have mounted a CIFS share (\\DESKTOP\modarchive) to "/media/usb0/games/Amiga/shared/" using the cifs_mount.sh script.

The idea being, I want to access my MOD Archive (that resides on a desktop computer) from ProTracker.

Workbench sees the files in the mount, it can be navigated, everything seems fine...but when I try to actually open any file through this share it fails. Protracker gives me a generic error, and Workbench freezes.

Any ideas?

[ferropop]

Any MiniMig users willing to test a Samba mount inside the Shared folder? I'm out of ideas :S

[ferropop]

Interesting : I tried this exact thing in FS-UAE and exact same issue!

[amstan]

I might have seen similar problems (MiSTer would say my cd folder is not found on AO486) when i had everything mounted via sshfs. But I just blamed it on sshfs being slow.

[mic64]

Hi

On standard Linux you have to use the crossmount option for that.
Guess it will work on Mister too.

[Bas]

Sshfs is a FUSE mount, that works differently from a mount managed by the Linux kernel filesystem drivers. Constructs like this one are a good reason to include NFS support in the MiSTer Linux environment as that's much more native to Linux than CIFS is.

[ferropop]

Sshfs is a FUSE mount, that works differently from a mount managed by the Linux kernel filesystem drivers. Constructs like this one are a good reason to include NFS support in the MiSTer Linux environment as that's much more native to Linux than CIFS is.

Thanks Bas, the curious thing is that this exact behaviour also happens in FS-UAE, where I set up the exact same scenario.

I wonder if the Amiga attempts to address the file system in some specific not-supported-by-SMB way, or it's a permissions thing?

Just odd that you can browse the share perfectly, you just can't interact with any of the actual files. Not even read!

[ferropop]

Should mention :

This is all set up on USB0 (a flash stick) with a games/Amiga folder that overrides the native games folder. I wonder if MiSTer's auto-remapping the games folder when present on external media, is adding to the complication here?

[Bas]

Well it shouldn't really. As far as the Amiga is concerned, Linux and whatever is in there doesn't exist. It just sees floppies and hard disks. The problem could be in file locking issues on the Linux end of things that are notorious across networked file systems. That would also explain FSUAE being similar. A protocol like ISCSI could tiptoe around this but isn't supported on MiSTer and also quite clunky for this use case.

Permissions could also be a thing. Is your Amiga allowed to write to the files or do you mount them read-only? In the latter case, things could go wrong because Amiga might expect the ability to update things like file metadata on access.

[Malor]

Check to see if you can access the files from the Linux command line; this will tell you whether or not you have a permissions problem. (ie, ssh into Mister, navigate to /media/usb0/games/Amiga/shared, and see if you can cat the files and see garbage.) I'd also do a ls -l and see what the provided username and permissions are.

If you can read the files there, the next step I'd try is unmounting the SMB share, and then trying to manually put a few files in that directory. Restart the Minimig core and see if you can read them. That will prove that the underlying mechanism is working.

If both those things work but the CIFS mount still fails, then I'd look into whatever service daemon is providing the files to the Amiga. It's probably doing something weird or nonstandard. Generally speaking, SMB is extremely compatible, because it's running directly through the kernel. I find it to almost always be better than NFS in almost every circumstance. It's faster, more reliable, and offers extra features like easy seeking within a file. Trying to play media over NFS is always a hassle, where it usually just works with SMB.

You might want to check any logs to see if you're getting errors. I'm not sure yet where Mister stores those, and I can't look right now. You could try dmesg to see if the kernel itself is complaining about something being wrong, but whatever service daemon talks to the Amiga and gets files on the Linux side is probably where the problem lies, assuming your SMB permissions are correct.

edit: keep in mind that if you're following the Wiki instructions, you'll have a unique 'mister' account for your SMB share. If you just copy files in, they'll be locked to your regular username, so the 'mister' user may not be able to read them. If that's the case, you'll want to add your regular account to the 'mister' group in /etc/groups, and log out and back in to get the new group permission attached to your session. Do a 'chgrp -R mister' on the entire host directory, and then do a 'chmod -R g+rwxs' on all the directories. That's the "group sticky bit", so any files or directories created will be in the mister group, and the directories will also be set to group sticky.

You also need to check your Samba permission masks so that the mister group is getting rwx permissions, assuming that you want to be able to update that area from the Mister board.

[Malor]

BTW, when I did it for myself, I went the other way: I set the user as mister and the group as my username group. (eg, if you're "johnsmith", this would be using the "johnsmith" group.) This is how my Samba config looks, with some redactions:

Code: Select all

[mister]
    browseable = yes
    path = /path/to/mister/dir
    guest ok = no
    read only = no
    create mask = 777
    directory mask = 777
    force user = mister
    force group = johnsmith

And then the root mister share (/path/to/mister/dir) is set u+rwx,g+rwxs. If you do this right away before any files get loaded, all the subdirs will inherit g+rwxs automatically.

I don't have a working SDRAM stick yet, won't until next week, so I can't test that the Minimig core can read from this, but I have this share loaded at /media/fat/cifs, and all the updates are putting files on the SMB share correctly.

[ferropop]

Wow Malor thank you so much for the comprehensive explanation. I'll try this right away. Really appreciate the insight!

[ferropop]

So, I took the "lawnmower to the moustache" approach and gave Full Permissions to Everyone on my Windows share. This fixed the problem. I'm gonna work backwards following your logic, and "re-secure" everything until I discover what was causing the issue. Thank you again!

[Malor]

Oh, if you're using actual Windows to make a Windows-style share, don't put permissions on the share itself. Instead, use NTFS permissions in the filesystem.

For best safety, you should create a new account ("mister" is good), with a new password, and have Mister use those in cifs_mount.sh. That data is in plaintext, and you're downloading and running a ton of code from a ton of people on that box. If your main user account and password are there, they're easily extracted if someone in the community goes rogue. (or has their project hijacked or hacked.)

Then use NTFS to add at least read permissions to the hosting directory, and probably write access as well, but probably not Full Control. If you set the permissions on the containing directory that you're sharing, you can click a checkbox to remove all permissions from the files below, instead having them all inherit from the one directory. That means you can manage the permissions for your entire collection on just one folder, instead of fifty thousand individual files. Further, all the files get added will have those same permissions again, so that's even less management you have to do.

[ferropop]

Oh, if you're using actual Windows to make a Windows-style share, don't put permissions on the share itself. Instead, use NTFS permissions in the filesystem.

For best safety, you should create a new account ("mister" is good), with a new password, and have Mister use those in cifs_mount.sh. That data is in plaintext, and you're downloading and running a ton of code from a ton of people on that box. If your main user account and password are there, they're easily extracted if someone in the community goes rogue. (or has their project hijacked or hacked.)

Then use NTFS to add at least read permissions to the hosting directory, and probably write access as well, but probably not Full Control. If you set the permissions on the containing directory that you're sharing, you can click a checkbox to remove all permissions from the files below, instead having them all inherit from the one directory. That means you can manage the permissions for your entire collection on just one folder, instead of fifty thousand individual files. Further, all the files get added will have those same permissions again, so that's even less management you have to do.

Really appreciate the thoughtful responses on all of this. Truly appreciated, what a cool and supportive community. All great points, thank you putting it in action rn.