FreeFileSync cannot see mounted NAS share in Fedora 37

Get help for specific problems
Posts: 7
Joined: 28 Nov 2022

doalffs

Hi all,

I updated my computer to Fedora 37 and installed FreeFileSync v11.28 from FlatHub.

I've been using FFS for many years for backing up my files to a NAS Share.
I do not keep the share permanently mounted in Fedora, I only mount it when I want to do a backup.

In the past, I would first mount the share in Nautilus file manager, then open FFS and it would appear as a destination. Now, even if I have mounted the share in Nautilus, the share does not appear in FFS at all.

The NAS has the IP address 10.10.10.6 and the share is called "backup", so I assume I could enter any of the following and one would work:
/run/user/1000/gvfs/smb-share:server=10.10.10.6,share=backup
or
//10.10.10.6/backup
or
smb://10.10.10.6/backup
but none of these works.

Has something changed?
Is there a way to manually add the share's full path to FFS?
Posts: 944
Joined: 8 May 2006

therube

Maybe the IP simply has changed, so instead of .6, it is now .5 (or whatever)?

If you:

ls //10.10.10.6/backup
ping 10.10.10.6

are results returned?
(I don't know if that would be valid for ls, but if not, then some other utility...)

(Long out of my league here, but, /etc/mtab or something like that?)
Posts: 7
Joined: 28 Nov 2022

doalffs

Yes, the NAS can be accessed as normal through the command line. I can also access all the share's files from the file manager, copy/paste/delete/rename etc.
It's only when trying to choose the share as a destination folder in FFS that the problem appears.
Posts: 306
Joined: 7 Jan 2018

bgstack15

If your SMB share is now mounted, it is accessible via a regular directory path. I would be very surprised if the path includes that string you mention with the colon, equal sign, and comma. A nice trick I use to learn the path to something is:
df -PBM
This shows disk space for all mounted drives. The flags are esoteric. The point is to list disk space for all mount points. Use the visible path for the mounted drive, as the path in FreeFileSync.
Posts: 7
Joined: 28 Nov 2022

doalffs

Thank you @bgstack15
Running the command you said only shows me the shares that I have permanently added onto /etc/fstab to be mounted on startup.

The mount that I am manually connecting to (Nautilus > Other locations > Connect to server) do not appear on the list that is shown with df -PBM

Any ideas?
Posts: 306
Joined: 7 Jan 2018

bgstack15

Nautilus is part of the GNOME software suite, which has fancy libraries available to it for looking at files. If we can use basic Linux filesystem mount commands to get to your network share, we can get FreeFileSync to see it too.
So it is obvious you know the hostname/IP address and the password to your SMB (akaCIFS) share. Let's make sure the mount.cifs command is available.
dnf install cifs-utils
Then we want to practice with the mount.cifs command until we get the flags correct, and then we'll save the settings into /etc/fstab (assuming you want this network share always available; defined but not auto-mounted is an option too, which I use on laptops).
This /net/backup is just an example path. You can select wherever to mount it.
sudo mkdir -p /net/backup
sudo mount.cifs -o username=doalffs,domain=WORKGROUP //10.10.10.6/backup /net/backup
You may of course include a password=PASSWORDHERE parameter but command parameters are basically world-readable on your computer. A way I use CIFS shares in production is with a credentials file.
sudo mount.cifs -o credentials=/etc/credentials.backup
Where /etc/credentials.backup contains exactly:
username=doalffs
password=UNESCAPEDPASSWORDHERE
domain=WORKGROUP
Domain is optional in all cases above.
You would want to lock down the /etc/credentials.backup file with:
sudo chmod 0600 /etc/credentials.backup
So that only the owner (presumably root) can read/write, and group and other have zero access.
Once you get any additional options available, and you want to add this to /etc/fstab (not necessary at all), you would want a line like this:
//10.10.10.6/backup      /net/backup      cifs     rw,uid=1000,noauto
Where uid is an option that sets the Linux-style file ownership visible to the users (i.e., you) of files on the CIFS/SMB to you. I'm guessing that your own user's UID is 1000. Whatever the third column of getent passwd ${USER} is, or echo $UID
What this uid parameter does is make all the files on this mounted path be owned by this user, because presumably you want to read and write the files on the remote filesystem you just mounted.
So the /etc/fstab entry will make the filesystem defined. The "noauto" prevents it from mounting at boot (or timing out trying to mount it at boot if it's unavailable), and also shields this filesystem from getting automounted when you run sudo mount -a.

/book
Posts: 7
Joined: 28 Nov 2022

doalffs

Thank you @bgstack15 for taking the time to write these very useful instructions, learned a lot from them.

Before I proceed with these (I've done a similar thing with a different share on the same NAS that I want to have automounted on boot and I used instructions very similar to yours), I am looking to understand why the same approach I was using in Fedora 35 is no longer working in Fedora 37.

I know this was working in Fedora 35 because I had been using it for a year on a daily basis and I last used it to transfer some files with FFS right before I did a clean install of Fedora 37. I would go to Nautilus > Other locations > Connect to server, connect to the NAS by typing the credentials, then open FFS and the share was there ready to use.

In fact, I quickly set up a VM with Fedora 35 and tested it again, and it still works there without any reference to the share in /etc/fstab at all. So I think either Fedora changed something, or FFS. But the FFS version I used to test it (11.28) was the same as the one in the production machine I have the problem with, which makes me think that Fedora might be the culprit here, not FFS.

Even crazier, I just noticed that the other share I automount on boot can be seen by FFS as normal. So I decided to add the "backup" share to /etc/fstab the exact same way I am mounting the other one:
//10.10.10.6/OTHER_SHARE /media/OTHER_SHARE cifs _netdev,file_mode=0777,dir_mode=0777,nofail,username=something,password=somethingelse 0 0
//10.10.10.6/backup /media/backup cifs _netdev,file_mode=0777,dir_mode=0777,nofail,username=something,password=somethingelse 0 0
I rebooted, and when I try to access the /backup share, I get an error saying:
this program is not installed setuid root - "user" CIFS mounts not supported
I can't, for the love of what's good, understand what is going on now!

Of course I understand this is not a Fedora support forum, so I will try to find some ideas on a different one.
Posts: 7
Joined: 28 Nov 2022

doalffs

Great spot @therube, we are getting there!

So I run:
sudo chmod u+s /bin/mount
sudo chmod u+s /bin/umount
sudo chmod u+s /usr/sbin/mount.cifs
Now, when I open the file manager (Nautilus) and I try to mount the share I get an error message:
mount.cifs: permission denied
But if I open the Terminal and type
sudo mount /media/backup
Then the share is mounted and can be seen from FFS!

So I now need to sort out 3 things:
- How to mount the share without opening the terminal (which I think is a permissions issue but I don't know how to solve it)
- How to ensure that the share is not mounted unless I actively click on it in the file manager
- How to avoid saving the credentials in fstab or on a separate credentials file and only be prompted to type them when I click on the share to mount it

Thank you for your assistance @therube and @bgstack15 , you are both amazing!
Posts: 7
Joined: 28 Nov 2022

doalffs

Just for reference for anyone else with the same issue, here's what's set up so far:

In the fstab file:
//10.10.10.6/backup /media/BACKUP cifs _netdev,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,noauto,username=YOURUSERNAME,password=YOURPASSWORD 0 0
Then I run:
sudo chmod u+s /bin/mount
sudo chmod u+s /bin/umount
sudo chmod u+s /usr/sbin/mount.cifs
And then I run:
sudo chown `whoami` /media/BACKUP
sudo chmod 700 /media/BACKUP
This allows for the share to be mounted with the command:
sudo mount /media/BACKUP
which then allows FFS to see the share and make use of it. When done, you can unmount the share using:
sudo umount /media/BACKUP
That's where I've reached so far with the help of @therube and @bgstack15
Posts: 306
Joined: 7 Jan 2018

bgstack15

If you are interested in something autoconnecting, research autofs. I think auto-mounting with autofs an SMB share would require a password saved somewhere, though. Sorry, I know mostly low-level things and not fancy gio stuff.

May I share that the /etc/fstab pretty much has to be world-readable (I recall once seeing it non-world-readable but I forget if it failed to operate correctly). That was one reason the mount.cifs guys added a credentials file option.

EDIT: despite my entirely leaving the Fedora desktop world, I still amuse myself by reading the changeset plans for the releases of Fedora GNU/Linux. Here's the plans for Fedora 37. I'm guessing any changes regarding the lack of setuid or fuse (Filesystems in USErspace or something like that) mounts being used by gio was too small to get described on these links.
Posts: 7
Joined: 28 Nov 2022

doalffs

Thank you @bgstack15, but I do not want to autoconnect to the share.
As my son may use my computer at times, I want to only be able to mount the share when I click on it and be asked to fill in credentials to connect. Despite his small size, he can be very destructive when it comes to computer use...
User avatar
Posts: 2287
Joined: 22 Aug 2012

Plerry

One option is to set up (at least) two accounts on your Fedora machine; one limited account for your sun (possibly even without login credentials), and (at least one) separate account for you, with login credentials.
For the latter account you could then use an auto-mount for your NAS share.

Or even better/safer, create two separate accounts for yourself; one simple, limited user account, that you would use for "normal" work and activities, and a second "administrator" account that you would use only when performing administrator related activities.