Access to gvfs-mounted smb directory limited: cannot create files but delete

Output from garuda-inxi below.

I'm moving from Ubuntu 20.04 LTS to Garuda Linux for a new laptop; I chose Garuda because it was the only distro that made the NVIDIA card run from the live system -- kudos! In my spare time I fiddle around with blender, just for fun and personal education.

I've set up a Raspi as a small server (nfs and smb, some static mounts). In this case the dynamic mount with Nautilus i.e. gvfs drives me crazy: I can open Blender files from Nautilus but cannot save/save-as them, error is: "permission denied". With Nautilus I can create files and folders, copy files to the mount and delete ... nothing remarkable.

Looking for the source of the problem I checked all settings on the Raspi and looked for differences between the old and new machine. Most searches for gvfs result in +/-10y old forum entries. I've learned a wee bit about gvfs and FUSE but nothing that solved my issue.

I can reproduce the behavior as follows (Note: error messages are not literal, both systems run in German, will change this for Garuda now).

Old laptop (Ubuntu 20.04.5 LTS)

  1. In Nautilus: mount the smb share with smb://<ip-address>/username, enter username and password
  2. cd /run/user/<uid>/gvfs/smb-share:server=<ip-address>,share=<username>
  3. touch x creates a new file x-- as expected
  4. cat > y creates a new file y -- as expected (may type some content, finish with Ctrl-D)

Version of gvfs is 1.44.1-1ubuntu1.1 (all packages listed with dpkg -l | grep gvfs)

New laptop (Garuda)

  1. same as above, same user
  2. same as above, same user
  3. touch z results in error message: "Cannot touch 'z', permission denied"
  4. cat > z results in "warning: An error occurred while redirecting file 'z'" and "open: permission denied"
  5. mv x z -- "cannot stat z, permission denied"
  6. touch x and cat >> x -- as expected since x already exists
  7. rm x -- as expected: deleted file x
  8. similarly mkdir won't work, but rmdir deletes without questions

Version of gvfs and gvfs-smb is 1.50.2-1

Things I tried

  • Different users on both machines, with and without admin privileges
  • The actual user logged in does not matter; the same behavior shows for a brand-new user
  • I checked all the file/directory permissions on the path, they look fine
  • Tested with a Windows laptop, Blender save works without problems

What happened before

From the fresh install: If I remember correctly Blender save was possible in the beginning -- don't know exactly what has changed though: I added a few users; I added the smb share to Nautilus with "never forget" credentials (installed Seashell and removed it); changed uids/guids (in /etc/passwd and /etc/group (and back to check if this was an error); added one nfs mount to /etc/fstab; added our extensive photo collection in Shotwell (archive is on nfs mount).

I wonder what the reason could be

  • Something with btrfs which is a main difference between the two systems
  • Differences in the version of gvfs (I found nothing striking in the release notes)
  • Some configuration issue for gvfs -- but why would one allow rm but not create new files?

Any help/hint appreciated! If there is any more information I can provide, please ask.

I'm not experienced with btrfs snapshots:

  • Would it be possible to go back and try the old behavior?
  • But I'd rather not lose the work I've done with our photos.

Thanks in advance!

  Kernel: 5.19.12-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=9c6fd0f2-7575-4c3e-859b-d832464e5fca rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    resume=UUID=be277372-da5e-4a26-a604-1cd532d0b7aa loglevel=3
  Desktop: GNOME v: 42.5 tk: GTK v: 3.24.34 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
  Type: Laptop System: HP product: OMEN Laptop 15-en1xxx v: N/A
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: HP model: 88D2 v: 75.53 serial: <superuser required> UEFI: AMI
    v: F.10 date: 07/28/2021
  ID-1: BAT0 charge: 71.0 Wh (100.0%) condition: 71.0/71.0 Wh (100.0%)
    volts: 13.0 min: 11.6 model: HP Primary type: Li-ion serial: <filter>
    status: not charging cycles: 6
  Device-1: hidpp_battery_0 model: Logitech MX Keys Wireless Keyboard
    serial: <filter> charge: 100% (should be ignored) rechargeable: yes
    status: discharging
  Info: model: AMD Ryzen 7 5800H with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 3 gen: 4 level: v3 built: 2021-22 process: TSMC n7 (7nm)
    family: 0x19 (25) model-id: 0x50 (80) stepping: 0 microcode: 0xA50000C
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB
    L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 1736 high: 3200 min/max: 1200/4462 boost: enabled
    scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 1200 2: 1200
    3: 1591 4: 3200 5: 1200 6: 3200 7: 1197 8: 1200 9: 3200 10: 1200 11: 1200
    12: 1200 13: 1200 14: 1200 15: 1397 16: 3200 bogomips: 102208
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: always-on, RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
  Device-1: NVIDIA GA104M [GeForce RTX 3070 Mobile / Max-Q]
    vendor: Hewlett-Packard driver: nvidia v: 515.76
    alternate: nouveau,nvidia_drm non-free: 515.xx+ status: current (as of
    2022-08) arch: Ampere code: GAxxx process: TSMC n7 (7nm) built: 2020-22
    pcie: gen: 3 speed: 8 GT/s lanes: 8 link-max: gen: 4 speed: 16 GT/s
    lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:249d class-ID: 0300
  Device-2: AMD Cezanne vendor: Hewlett-Packard driver: amdgpu v: kernel
    arch: GCN-5.1 code: Vega-2 process: TSMC n7 (7nm) built: 2018-21 pcie:
    gen: 3 speed: 8 GT/s lanes: 16 link-max: gen: 4 speed: 16 GT/s ports:
    active: eDP-1 empty: none bus-ID: 06:00.0 chip-ID: 1002:1638
    class-ID: 0300
  Device-3: Polycom EagleEye Mini Camera type: USB
    driver: hid-generic,usbhid,uvcvideo bus-ID: 1-2.2.2:7 chip-ID: 095d:3001
    class-ID: 0300 serial: <filter>
  Device-4: Quanta HP Wide Vision HD Camera type: USB driver: uvcvideo
    bus-ID: 1-3:3 chip-ID: 0408:5425 class-ID: fe01 serial: <filter>
  Display: x11 server: X.Org v: 21.1.4 with: Xwayland v: 22.1.3
    compositor: gnome-shell driver: X:
    loaded: amdgpu,modesetting,nouveau,nvidia,radeon alternate: fbdev,nv,vesa
    gpu: amdgpu,evdi display-ID: :1 screens: 1
  Screen-1: 0 s-res: 5760x2160 s-dpi: 96 s-size: 1524x572mm (60.00x22.52")
    s-diag: 1628mm (64.09")
  Monitor-1: DVI-I-1 mapped: DVI-I-2-1 pos: primary,top-left model: LG
    (GoldStar) Ultra HD serial: <filter> built: 2018 res: 3840x2160 hz: 60
    dpi: 163 gamma: 1.2 size: 600x340mm (23.62x13.39") diag: 690mm (27.2")
    ratio: 16:9 modes: max: 3840x2160 min: 640x480
  Monitor-2: eDP-1 mapped: eDP pos: primary,bottom-r model: LG Display
    0x05fe built: 2018 res: 1920x1080 hz: 144 dpi: 142 gamma: 1.2
    size: 344x194mm (13.54x7.64") diag: 395mm (15.5") ratio: 16:9 modes:
    max: 1920x1080 min: 640x480
  Message: Unable to show GL data. Required tool glxinfo missing.
  Device-1: NVIDIA GA104 High Definition Audio vendor: Hewlett-Packard
    driver: snd_hda_intel v: kernel bus-ID: 2-2.1:3 chip-ID: 17e9:6006 pcie:
    class-ID: 0a00 gen: 3 speed: 8 GT/s serial: <filter> lanes: 8 link-max:
    gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:228b
    class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Hewlett-Packard
    driver: snd_rn_pci_acp3x v: kernel
    alternate: snd_pci_acp3x,snd_pci_acp5x,snd_pci_acp6x,snd_acp_pci,snd_sof_amd_renoir
    pcie: gen: 3 speed: 8 GT/s lanes: 16 link-max: gen: 4 speed: 16 GT/s
    bus-ID: 06:00.5 chip-ID: 1022:15e2 class-ID: 0480
  Device-3: AMD Family 17h/19h HD Audio vendor: Hewlett-Packard
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
    link-max: gen: 4 speed: 16 GT/s bus-ID: 06:00.6 chip-ID: 1022:15e3
    class-ID: 0403
  Device-4: DisplayLink Dell Universal Dock D6000 type: USB
    driver: cdc_ncm,snd-usb-audio,usbfs
  Sound Server-1: ALSA v: k5.19.12-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 16.1 running: no
  Sound Server-3: PipeWire v: 0.3.58 running: yes
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: Hewlett-Packard driver: r8169 v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 port: e000 bus-ID: 02:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: eno1 state: down mac: <filter>
  Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 1 bus-ID: 03:00.0 chip-ID: 8086:2723 class-ID: 0280
  IF: wlo1 state: up mac: <filter>
  IF-ID-1: enp6s0f3u2u1i5 state: up speed: 1000 Mbps duplex: half
    mac: <filter>
  Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-4:12 chip-ID: 8087:0029 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 2 state: up address: <filter>
  Local Storage: total: 476.94 GiB used: 31.69 GiB (6.6%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung
    model: MZVLB512HBJQ-000H1 size: 476.94 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: HPS0NEXF temp: 29.9 C scheme: GPT
  ID-1: / raw-size: 460.16 GiB size: 460.16 GiB (100.00%) used: 31.69 GiB
    (6.9%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%) used: 608 KiB
    (0.2%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 460.16 GiB size: 460.16 GiB (100.00%) used: 31.69
    GiB (6.9%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-4: /var/log raw-size: 460.16 GiB size: 460.16 GiB (100.00%) used: 31.69
    GiB (6.9%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-5: /var/tmp raw-size: 460.16 GiB size: 460.16 GiB (100.00%) used: 31.69
    GiB (6.9%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 14.98 GiB used: 8 MiB (0.1%) priority: 100
    dev: /dev/zram0
  ID-2: swap-2 type: partition size: 16.48 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p3 maj-min: 259:3
  System Temperatures: cpu: 53.5 C mobo: N/A gpu: amdgpu temp: 46.0 C
  Fan Speeds (RPM): fan-1: 0 fan-2: 0
  Processes: 384 Uptime: 3h 32m wakeups: 6 Memory: 14.98 GiB used: 8.48 GiB
  (56.6%) Init: systemd v: 251 default: graphical tool: systemctl
  Compilers: gcc: 12.2.0 alt: 11 clang: 14.0.6 Packages: pm: pacman
  pkgs: 1226 libs: 343 tools: pamac,paru Shell: fish v: 3.5.1 default: Bash
  v: 5.1.16 running-in: gnome-terminal inxi: 3.3.21
Garuda (2.6.8-1):
  System install date:     2022-09-15
  Last full system update: 2022-10-02
  Is partially upgraded:   No
  Relevant software:       NetworkManager
  Windows dual boot:       Probably (Run as root to verify)
  Snapshots:               Snapper
  Failed units:            

Snapshots restore only / not /home, until you changed it.



I have also seen odd behavior with gvfs mounts--just as you describe, where the GUI file manager seems to work fine but if I drop to the terminal, not only is the mountpoint itself long and clunky but sometimes permissions are broken.

In my case, the shares started working rather painlessly after I made a proper mount point and add it to the fstab. An added bonus is you can source a credential file if you want to, with username and password so you don't have to sign in every time you access the resource.

Here is the relevant documentation: Samba - ArchWiki

Make a mount point for your share wherever you like.

sudo mkdir /mnt/smb
sudo chown -R josch:josch /mnt/smb

Add an fstab entry using the mountpoint.

//*SERVER*/*sharename* /mnt/smb cifs _netdev,nofail,username=*myuser*,password=*mypass* 0 0

:point_up: That example is straight out of the ArchWiki article. It's a good starting place. There are many more options you can add (after the mount point); I recommend adding the x-systemd.automount option, so it is only mounted when accessing the share (instead of trying to mount it at boot time, which can make booting clunky since it has to wait for the network).

You can also add the users option (yes, with an "s"), which allows users to mount it as long as it is in a directory the user has permission to.

Also, instead of passing username=*myuser*,password=*mypass* in plaintext, you can use cred= and specify a file with credentials. That is useful if fstab is visible to users who should not see the credentials. See how to set it up in the man pages here: mount.cifs(8) — Arch manual pages

After you've got it all set up, you should be able to cd /mnt/smb without even having to sign in--it's just another resource on the directory tree.

This should not be /username, it should be the name of the share. In your case that may be the same value, but I thought I would mention it in case it matters at some point.

This shouldn't be a problem. The only filesystem that is likely to cause additional grief would be NTFS, which has it's own elaborate system of special handling that is needed.

Some folks like to set up snapshots for /home, but for various reasons it is not set up that way by default and needs to be set up by the user separately. If you have not done that, you should be able to restore a snapshot without it touching your photos (assuming you are storing them somewhere in /home).

SGS is right though--make a backup of the photos first! :wink:


I like this attitude and adopted it for me: No backup, no mercy. You're totally right.

Snapshots restore only / not /home

Good to know about these snapshots;
default is keeping 10, frequent updates, many installs ... so no help here.

I don't like that I don't understand what's going on.

  • Why can I rm but not touch in this directory? So, no save from Blender.
  • Why is this possible from a different computer?

Even if I set up this new laptop from scratch (might have taken less time), this behavior still would be nagging at me ...

Do you understand why this happens? And why it works from the other PC?

I don't care too much about the mountpoint being clunky: Open form Nautilus with a double click will launch Blender, Ctrl-S should save it. It just helped me pinpointing the problem switching to console.

Totally correct; I made the samba server on the Pi export the home directories, so the name of the share is the actual username. Thanks for pointing this out.

I checked if this behavior happens for "normal" shares, too: It does :frowning:

Got this, thanks, also for the long write up. As I mentioned I've done this for an NFS share already (there's the archive of my photos, which I backup regularily). There were some things that held me back for smb shares, though (can't remember which now, maybe the pw in plain sight was one of them--thanks for the hint here, too).

Maybe I'll resort to this in the end (still nagging, see above).

To be honest, no--I don't really know why. A couple possibilities come to mind:

  • There could be an issue with the gvfs package, a bug or otherwise.

Don't forget, you are using a different package on the machine that is exhibiting the expected behavior:

Who knows if Ubuntu has made a special version of the package to resolve a bug with the upstream version or similar?

  • There could be an issue with the final configuration on your machine.

This theory is supported by the fact that, as you mentioned, it was initially working as expected and then stopped after a few changes had been made to the system.

But as I said, I really don't know why you end up with that wacky behavior.

I sympathize with your desire to figure out why it's not working the way you expect. I still think setting up a proper mount in fstab is going to solve your issue.

You can continue to use the clunky run/user/1000/gvfs/blah-blah-blah mount point if you wish (a resource can have multiple mount points). On my system, now that I have the device correctly mounted I am able to use either mount point and they both behave normally (so far, knock on wood :wink:).


I'll accept this as answer:

  • smb mount in /etc/fstab and keep trying to figure out, what's wrong
  • If I'll ever discover, I'll add it here

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.