Can't write to a file in mounted Samba share in Fedora Silverblue 40, but can in Fedora Workstation 39 and Debian 12

I created a Samba server on a Raspberry Pi, and I have no trouble accessing and using the server with GNOME’s Files/Nautilus in Fedora Workstation 39 live and Debian 12.

But in Fedora Silverblue 40, I can create, delete and rename files, but I cannot write to them.

My UID and GID is 1000/1000 on all systems.

Here is a sample log line from when the save fails in Silverblue 40:

Jun 07 13:50:50 hp-envy-silverblue gnome-text-edit[5142]: Failed to save document: Error opening file “/run/user/1000/doc/6bf18bce/text”: Operation not supported

I’m thinking this must be something in Silverblue, since I don’t have a problem with the Workstation live image or Debian.

Plus it’s only writing to files – and I CAN write to files on the Samba server on the non-Silverblue systems.

This is what I’ve added to /etc/samba/smb.conf on the server:

[homestead]
path = /media/usb/samba/
browseable = yes
writeable = yes
only guest = no
create mask = 0777
directory mask = 0777
public = yes
guest ok = yes

Remember, two other Linux systems on the same local network have no problem with this Samba server. It’s just the Silverblue system that can’t write to a file.

Any ideas?

Did you have a look at the change set from F40?

While I had a quick look, I saw openssl 1.1 and pyton v.3.7 retirement This apps have been available till F39.

Also move /var/run selinux-policy entries to /run # tha’t is my guess for the error.
Some environmental variable still pointing to the old place for an older app?

I just confirmed that I CAN write to a file on my Samba share from Files/Nautilus in Fedora Workstation 40. I also succeeded with CentOS Stream 9.

That means this problem is confined to Fedora Silverblue.

I don’t know which package to file a bug against.

Is there a simlnk to /var for /media ? Silverblue’s root filesystem is read only.
Technical Information :: Fedora Docs >> File system Layout

Please check with ls -al / to see if there is a simlink.

The Samba server is not on Silverblue. It’s on a Raspberry Pi running RPi OS.

The problem is with Silverblue as a client for the Samba share.

1 Like

Ok, sorry.

Above I asked you to check in Silverblue and not on the Workstation Legacy!

This sounds quite exactly what you have … problem with your userspace:

:link: Move /var/run selinux-policy entries to /run

Actual path for system runtime files moved from /var/run to /run some 10 years ago [1], but the policy has been managed since then in a way that keeps the old entries and have updates still with the incorrect path while the real path is handled by file equivalency feature. This can confuse sysadmins not to be sure which path should be actually used and can also effect in userspace tools not working properly [2].

After a lot of testing, I learned some things, and I think I can mark this as a solution.

It’s not that the Samba share is or isn’t working in Fedora Silverblue, or any other Unix/Linux system. Samba is working fine. I was able to mount the share via Files/Nautilus in Debian and Fedora Silverblue, and in Thunar (and Gigolo) with the gvfs-smb package in OpenBSD.

The problem has been with apps I am using to work with the files on the Samba share. Some work, others do not.

And the issue is with the gvfs filesystem that is used to mount the Samba shares. The issues are the same when an sftp site is mounted via gvfs in Nautilus/Files.

When I discovered the same issues in Nautilus/Files with sftp, I knew my problem had nothing to do with Samba, per se.

It was gvfs – specifically the apps that can and can’t work with a gvfs-mounted filesystem.

What threw me was that in Debian 12, I was using a text editor (Gedit) that works well with gvfs, and In Fedora, my editor (GNOME Text Editor) does not work terribly well in that environment.

So I did a bunch of testing across Debian 12 and Fedora Silverblue 40 (with GNOME) and OpenBSD 7.5 (with Xfce).

It all depends on which applications you are using to read and write to files in a gvfs filesystem.

Here’s what I learned:

Apps that work with GVFS filesystems:

  • LibreOffice Writer (I haven’t tested other programs in the office suite, but this one is a champ)
  • Gedit (Used to be my go-to text editor … might return to the throne)
  • Emacs (GUI version via Flatpak. The first save of a file throws a chmod error, but it’s smooth after that)
  • Kate
  • Kwrite (Great showing from the KDE apps)
  • Neovim (file opens in the terminal app with the GNOME file-open dialog. I’m surprised this works where Vim does not)

Apps that read only and can’t write:

  • GNOME Text Editor
  • Vim (Flatpak in terminal)

Apps that don’t work at all:

  • Geany
  • GVim

Apps that read and write, but not seamlessly

  • Mousepad (tested in OpenBSD, a dialog says the file wasn’t written, but it actually is. The dialog is annoying)

Update: The lack of consistency in apps being able to edit files in gvfs-mounted filesystems isn’t a Silverblue/Atomic problem. It’s a Flatpak problem.

Some Flatpaks (like Emacs and LibreOffice) deal well with gvfs, others (GNOME Text Editor, Geany) do not.

But so far, I have had no issues with apps installed the “traditional” way (dnf in Fedora, apt in Debian).

I’m not excited about layering editors in Silverblue (though I did it in the past with Vim), but I will do it for science.

tl;dr It’s not Silverblue or Fedora, it’s Flatpak.

1 Like

I’d like to update and clarify my previous solution on how to edit files in Samba shares via the Files/Nautilus file manager. As far as I can tell, the same things work/don’t work in Xfce’s Thunar.

  • My go-to text editor for files in Samba shares is Gedit. Works everywhere, every time.
  • Other editors that work every time are Kwrite and Kate.
  • Emacs works.
  • Mousepad kind of works. It says it didn’t save but prompts you to reload the file, which has in fact been saved.
  • The LibreOffice suite seems to LOVE Samba shares. Writer works every time.

I don’t think this has anything to do with Flatpaks or Silverblue. I have done my tests in Silverblue and OpenBSD with Xfce, and the apps that work will work in any Linux/Unix system.

1 Like

I have the exact same problem and for the past couple of days i’ve been messing around with flatpak permissions trying to solve it. I’ve been using gnome text editor as an example of an app that doesn’t work and gedit as an app that does work.
I used flatseal to make sure the both have the same permissions and the only difference using the default permissions is that gnome text editor has GPU acceleration enabled.
Disabling this so that they have the exact same permissions doesn’t solve the issue which makes me think that the problem is the code of the app and not an issue with flatpak.

However I did some searching and landed on this issue where the bottom comment leads to this:

--filesystem=xdg-run/gvfs is necessary to give access to the FUSE mounts non-GIO and legacy applications can use. This is what will make native files appear under /run/user/id -u/gvfs/.

Adding this permission solves the issue. I do not now how or why but I tried it on gnome text editor and apostrophe (another app with the same issue) and it fixed it for both of them.
Note that you can remove the --filesystem=xdg-run/gvfsd permission but it does cause some errors in the logs so I just added them both. (It also still has this permission: --talk-name=org.gtk.vfs.*)

I find this very strange because in that documentation it mentions that gvfsd should be used for typical gnome and gtk apps and gvfs for typical non-gnome and non-gtk apps.
I would think that gnome text editor is a typical gnome app but apparently not.

I don’t know if this has any serious side effects tho like creating a huge security hole in the sandbox or something but I know I’m happy because it fixed my issue.

Also I’m wondering if and where we need to open a bug report because this should just work out of the box.

1 Like

This is an interesting solution. I’ll have to try it.

Now I get it, the permission that the GNOME Text Editor Flatpak ships with, as seen in Flatseal, is:

xdg-run/gvfsd

But for it to work, I needed to add:

xdg-run/gvfs

I already had:

org.gtk.vfs.*

Now it works – thanks @thaticypolarbear !!

Here are some images of what the config for GNOME Text Editor look like in Flatseal:


I’ll have to try this with the Geany Flatpak.

Those permissions DID work for the GVim Flatpak but not for the Geany Flatpak.

All in all, a huge win!

I figured something out. I’m trying the Fedora LXQt spin, and I wasn’t able to get my Samba share mounted via the PCManFM-QT file manager.

So I tried to use mount in the terminal to open the share in a folder.

At first it worked, but the files were owned by root, and I couldn’t edit them.

I did some searches, and this page provided me enough info to get the Samba share mounted, and for the first time I can edit with EVERY app I have.

The “tools” I needed to form my mount command came from:

And this is how I mount the share so my local user can read it (all of this on one line in the terminal):

sudo mount -t cifs //192.168.1.47/steven samba -o rw,username=steven,uid=1000,gid=1000

This is a solution for a traditional Fedora system with local (not Flatpak) apps, but I will test and see how this works in Silverblue and add to the thread.

1 Like