Cannot modify files installed by `snap`

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
3
down vote

favorite












I have installed a package using snap and I need to modify one of the files but when I try to change its ownership or permissions, I always get the following message:



sudo chmod +x ./my_file.js
chmod: changing permissions of '/snap/my_app/my_file.js': Read-only file system


How can I modify files that are installed via snap?







share|improve this question





















  • I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
    – L. D. James
    May 15 at 17:47











  • Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
    – Miladiouss
    May 15 at 20:19










  • I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
    – L. D. James
    May 15 at 21:22










  • ...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
    – L. D. James
    May 15 at 21:26














up vote
3
down vote

favorite












I have installed a package using snap and I need to modify one of the files but when I try to change its ownership or permissions, I always get the following message:



sudo chmod +x ./my_file.js
chmod: changing permissions of '/snap/my_app/my_file.js': Read-only file system


How can I modify files that are installed via snap?







share|improve this question





















  • I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
    – L. D. James
    May 15 at 17:47











  • Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
    – Miladiouss
    May 15 at 20:19










  • I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
    – L. D. James
    May 15 at 21:22










  • ...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
    – L. D. James
    May 15 at 21:26












up vote
3
down vote

favorite









up vote
3
down vote

favorite











I have installed a package using snap and I need to modify one of the files but when I try to change its ownership or permissions, I always get the following message:



sudo chmod +x ./my_file.js
chmod: changing permissions of '/snap/my_app/my_file.js': Read-only file system


How can I modify files that are installed via snap?







share|improve this question













I have installed a package using snap and I need to modify one of the files but when I try to change its ownership or permissions, I always get the following message:



sudo chmod +x ./my_file.js
chmod: changing permissions of '/snap/my_app/my_file.js': Read-only file system


How can I modify files that are installed via snap?









share|improve this question












share|improve this question




share|improve this question








edited May 13 at 15:33









xiota

1,0461421




1,0461421









asked May 12 at 0:40









Miladiouss

1559




1559











  • I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
    – L. D. James
    May 15 at 17:47











  • Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
    – Miladiouss
    May 15 at 20:19










  • I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
    – L. D. James
    May 15 at 21:22










  • ...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
    – L. D. James
    May 15 at 21:26
















  • I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
    – L. D. James
    May 15 at 17:47











  • Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
    – Miladiouss
    May 15 at 20:19










  • I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
    – L. D. James
    May 15 at 21:22










  • ...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
    – L. D. James
    May 15 at 21:26















I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
– L. D. James
May 15 at 17:47





I see you recently changed your question. However, my answer and comments still apply to the new question. App development really should be done in your own personal space, or a shared development area. The files that you think should be modified should be addressed on the development level and places according to how you want the user to have access to them. If the program is creating the files you are trying to manually modify, make that change in the app so that it will create the file correctly. Root shouldn't be used until you are in the process of making a system-wide installation.
– L. D. James
May 15 at 17:47













Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
– Miladiouss
May 15 at 20:19




Thank you James, I was trying to integrate math with Slack, I was not developing a package. See this for more examples: github.com/fsavje/math-with-slack
– Miladiouss
May 15 at 20:19












I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
– L. D. James
May 15 at 21:22




I understand that from your original question about the read/only characteristic when you still couldn't do it from a elevated sudo command. My suggestion was then, with is consistent, is that you really shouldn't have to work on the program and development from sudo. The /snap/my_app/my_file.js appeared to be a project that you were working on. Your recent comment still appears to suggest the same. Even if it's slightly different, it would be best to work on the your integration project in your personal space by a non-elevated user account and (develope), work on it that way.
– L. D. James
May 15 at 21:22












...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
– L. D. James
May 15 at 21:26




...(continued) working and developing it in /snap isn't the best and most secure method. Making the system-wide change, while you're working and debugging it could cause a undesirable integrity effect of your snap installation ( or your overall system's integrity). You can easily make the changes to the data files if you bring your project into your personal space. Once you get it working the way you want it, you can then apply your changes and patches necessary to the /snap (which is system-wide) environment.
– L. D. James
May 15 at 21:26










2 Answers
2






active

oldest

votes

















up vote
4
down vote



accepted










Snap partitions use SquashFS, which is basically a compressed, read-only disk image format that is usually used to create live CDs/DVDs. SquashFS was simply not designed to be read-write. To edit the contents, even something as simple as changing file permissions, cannot be done through a simple remount.



Your options are:




  • Rebuild the SquashFS file system. The following resources should be helpful:



    • Modifying a squashfs

    • How to modify squashfs image


  • Use OverlayFS to save changes separately.


If you would like to become a Snap developer, you might like to start with this tutorial to create your first snap.






share|improve this answer























  • That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
    – Miladiouss
    May 12 at 8:20

















up vote
0
down vote













Snap's program files are protected against change. This is done by the process of mounting the protected files in their specific space as read only.



The process also has specific space for configuration data which includes the user's specific home space (/home/user/snap) for data and configurations and a space for world-wide data (/var/snap).



All the world-wide snap files are readable and accessible via symbolic links to the /snap area.



You can verify the real location and how the spaces are linked with the following commands.



A command to see examples of snap's protected mounts:



$ mount | egrep snap | egrep ro,
/var/lib/snapd/snaps/core_4486.snap on /snap/core/4486 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/communitheme_185.snap on /snap/communitheme/185 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/hello-world_27.snap on /snap/hello-world/27 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/core_4407.snap on /snap/core/4407 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/communitheme_124.snap on /snap/communitheme/124 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_4571.snap on /snap/core/4571 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/communitheme_246.snap on /snap/communitheme/246 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/vlc_190.snap on /snap/vlc/190 type squashfs (ro,nodev,relatime,x-gdu.hide)


A command to see examples of snap's spaces that are not write protected:



$ mount | egrep snap | egrep -v ro,
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3293156k,mode=755)
nsfs on /run/snapd/ns/hello-world.mnt type nsfs (rw)
nsfs on /run/snapd/ns/vlc.mnt type nsfs (rw)


By your error message you are trying to make change on files that have been programmably protected by the programmer. Your question suggests that you are the app's programmer. So you would have to use the features of snap's programming configuration to decide which files will be placed where.



How can I resolve this?



As I suggested in the comments, it would be safer and more common for you to design your program in a development environment as a normal user... normally in your own personal space, then use the snap's development system for installing the new version.



I'm not a snap programmer and can't give exact specifics of how the designing and export for use process works with snap. But I can imagine it might be similar to designing Android, or Java programs, where the developer will use some type of export or publish method to run or to test the new version in an installed configuration.



You could possibly experiment with remounting the protected read-only filesystems to read/write. I wouldn't advise it, because it might be possible to break the integrity of the snap system, or provide unexpected behavior where your application may not behave as intended because of the modification of the snap system itself.






share|improve this answer





















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "89"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1035127%2fcannot-modify-files-installed-by-snap%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote



    accepted










    Snap partitions use SquashFS, which is basically a compressed, read-only disk image format that is usually used to create live CDs/DVDs. SquashFS was simply not designed to be read-write. To edit the contents, even something as simple as changing file permissions, cannot be done through a simple remount.



    Your options are:




    • Rebuild the SquashFS file system. The following resources should be helpful:



      • Modifying a squashfs

      • How to modify squashfs image


    • Use OverlayFS to save changes separately.


    If you would like to become a Snap developer, you might like to start with this tutorial to create your first snap.






    share|improve this answer























    • That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
      – Miladiouss
      May 12 at 8:20














    up vote
    4
    down vote



    accepted










    Snap partitions use SquashFS, which is basically a compressed, read-only disk image format that is usually used to create live CDs/DVDs. SquashFS was simply not designed to be read-write. To edit the contents, even something as simple as changing file permissions, cannot be done through a simple remount.



    Your options are:




    • Rebuild the SquashFS file system. The following resources should be helpful:



      • Modifying a squashfs

      • How to modify squashfs image


    • Use OverlayFS to save changes separately.


    If you would like to become a Snap developer, you might like to start with this tutorial to create your first snap.






    share|improve this answer























    • That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
      – Miladiouss
      May 12 at 8:20












    up vote
    4
    down vote



    accepted







    up vote
    4
    down vote



    accepted






    Snap partitions use SquashFS, which is basically a compressed, read-only disk image format that is usually used to create live CDs/DVDs. SquashFS was simply not designed to be read-write. To edit the contents, even something as simple as changing file permissions, cannot be done through a simple remount.



    Your options are:




    • Rebuild the SquashFS file system. The following resources should be helpful:



      • Modifying a squashfs

      • How to modify squashfs image


    • Use OverlayFS to save changes separately.


    If you would like to become a Snap developer, you might like to start with this tutorial to create your first snap.






    share|improve this answer















    Snap partitions use SquashFS, which is basically a compressed, read-only disk image format that is usually used to create live CDs/DVDs. SquashFS was simply not designed to be read-write. To edit the contents, even something as simple as changing file permissions, cannot be done through a simple remount.



    Your options are:




    • Rebuild the SquashFS file system. The following resources should be helpful:



      • Modifying a squashfs

      • How to modify squashfs image


    • Use OverlayFS to save changes separately.


    If you would like to become a Snap developer, you might like to start with this tutorial to create your first snap.







    share|improve this answer















    share|improve this answer



    share|improve this answer








    edited May 13 at 21:32


























    answered May 12 at 5:30









    xiota

    1,0461421




    1,0461421











    • That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
      – Miladiouss
      May 12 at 8:20
















    • That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
      – Miladiouss
      May 12 at 8:20















    That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
    – Miladiouss
    May 12 at 8:20




    That sounds about right. Thanks. Can you direct me to a starting point please. Never done this before.
    – Miladiouss
    May 12 at 8:20












    up vote
    0
    down vote













    Snap's program files are protected against change. This is done by the process of mounting the protected files in their specific space as read only.



    The process also has specific space for configuration data which includes the user's specific home space (/home/user/snap) for data and configurations and a space for world-wide data (/var/snap).



    All the world-wide snap files are readable and accessible via symbolic links to the /snap area.



    You can verify the real location and how the spaces are linked with the following commands.



    A command to see examples of snap's protected mounts:



    $ mount | egrep snap | egrep ro,
    /var/lib/snapd/snaps/core_4486.snap on /snap/core/4486 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/communitheme_185.snap on /snap/communitheme/185 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/hello-world_27.snap on /snap/hello-world/27 type squashfs (ro,nodev,relatime)
    /var/lib/snapd/snaps/core_4407.snap on /snap/core/4407 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/communitheme_124.snap on /snap/communitheme/124 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/core_4571.snap on /snap/core/4571 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/communitheme_246.snap on /snap/communitheme/246 type squashfs (ro,nodev,relatime,x-gdu.hide)
    /var/lib/snapd/snaps/vlc_190.snap on /snap/vlc/190 type squashfs (ro,nodev,relatime,x-gdu.hide)


    A command to see examples of snap's spaces that are not write protected:



    $ mount | egrep snap | egrep -v ro,
    tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3293156k,mode=755)
    nsfs on /run/snapd/ns/hello-world.mnt type nsfs (rw)
    nsfs on /run/snapd/ns/vlc.mnt type nsfs (rw)


    By your error message you are trying to make change on files that have been programmably protected by the programmer. Your question suggests that you are the app's programmer. So you would have to use the features of snap's programming configuration to decide which files will be placed where.



    How can I resolve this?



    As I suggested in the comments, it would be safer and more common for you to design your program in a development environment as a normal user... normally in your own personal space, then use the snap's development system for installing the new version.



    I'm not a snap programmer and can't give exact specifics of how the designing and export for use process works with snap. But I can imagine it might be similar to designing Android, or Java programs, where the developer will use some type of export or publish method to run or to test the new version in an installed configuration.



    You could possibly experiment with remounting the protected read-only filesystems to read/write. I wouldn't advise it, because it might be possible to break the integrity of the snap system, or provide unexpected behavior where your application may not behave as intended because of the modification of the snap system itself.






    share|improve this answer

























      up vote
      0
      down vote













      Snap's program files are protected against change. This is done by the process of mounting the protected files in their specific space as read only.



      The process also has specific space for configuration data which includes the user's specific home space (/home/user/snap) for data and configurations and a space for world-wide data (/var/snap).



      All the world-wide snap files are readable and accessible via symbolic links to the /snap area.



      You can verify the real location and how the spaces are linked with the following commands.



      A command to see examples of snap's protected mounts:



      $ mount | egrep snap | egrep ro,
      /var/lib/snapd/snaps/core_4486.snap on /snap/core/4486 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/communitheme_185.snap on /snap/communitheme/185 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/hello-world_27.snap on /snap/hello-world/27 type squashfs (ro,nodev,relatime)
      /var/lib/snapd/snaps/core_4407.snap on /snap/core/4407 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/communitheme_124.snap on /snap/communitheme/124 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/core_4571.snap on /snap/core/4571 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/communitheme_246.snap on /snap/communitheme/246 type squashfs (ro,nodev,relatime,x-gdu.hide)
      /var/lib/snapd/snaps/vlc_190.snap on /snap/vlc/190 type squashfs (ro,nodev,relatime,x-gdu.hide)


      A command to see examples of snap's spaces that are not write protected:



      $ mount | egrep snap | egrep -v ro,
      tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3293156k,mode=755)
      nsfs on /run/snapd/ns/hello-world.mnt type nsfs (rw)
      nsfs on /run/snapd/ns/vlc.mnt type nsfs (rw)


      By your error message you are trying to make change on files that have been programmably protected by the programmer. Your question suggests that you are the app's programmer. So you would have to use the features of snap's programming configuration to decide which files will be placed where.



      How can I resolve this?



      As I suggested in the comments, it would be safer and more common for you to design your program in a development environment as a normal user... normally in your own personal space, then use the snap's development system for installing the new version.



      I'm not a snap programmer and can't give exact specifics of how the designing and export for use process works with snap. But I can imagine it might be similar to designing Android, or Java programs, where the developer will use some type of export or publish method to run or to test the new version in an installed configuration.



      You could possibly experiment with remounting the protected read-only filesystems to read/write. I wouldn't advise it, because it might be possible to break the integrity of the snap system, or provide unexpected behavior where your application may not behave as intended because of the modification of the snap system itself.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        Snap's program files are protected against change. This is done by the process of mounting the protected files in their specific space as read only.



        The process also has specific space for configuration data which includes the user's specific home space (/home/user/snap) for data and configurations and a space for world-wide data (/var/snap).



        All the world-wide snap files are readable and accessible via symbolic links to the /snap area.



        You can verify the real location and how the spaces are linked with the following commands.



        A command to see examples of snap's protected mounts:



        $ mount | egrep snap | egrep ro,
        /var/lib/snapd/snaps/core_4486.snap on /snap/core/4486 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_185.snap on /snap/communitheme/185 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/hello-world_27.snap on /snap/hello-world/27 type squashfs (ro,nodev,relatime)
        /var/lib/snapd/snaps/core_4407.snap on /snap/core/4407 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_124.snap on /snap/communitheme/124 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/core_4571.snap on /snap/core/4571 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_246.snap on /snap/communitheme/246 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/vlc_190.snap on /snap/vlc/190 type squashfs (ro,nodev,relatime,x-gdu.hide)


        A command to see examples of snap's spaces that are not write protected:



        $ mount | egrep snap | egrep -v ro,
        tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3293156k,mode=755)
        nsfs on /run/snapd/ns/hello-world.mnt type nsfs (rw)
        nsfs on /run/snapd/ns/vlc.mnt type nsfs (rw)


        By your error message you are trying to make change on files that have been programmably protected by the programmer. Your question suggests that you are the app's programmer. So you would have to use the features of snap's programming configuration to decide which files will be placed where.



        How can I resolve this?



        As I suggested in the comments, it would be safer and more common for you to design your program in a development environment as a normal user... normally in your own personal space, then use the snap's development system for installing the new version.



        I'm not a snap programmer and can't give exact specifics of how the designing and export for use process works with snap. But I can imagine it might be similar to designing Android, or Java programs, where the developer will use some type of export or publish method to run or to test the new version in an installed configuration.



        You could possibly experiment with remounting the protected read-only filesystems to read/write. I wouldn't advise it, because it might be possible to break the integrity of the snap system, or provide unexpected behavior where your application may not behave as intended because of the modification of the snap system itself.






        share|improve this answer













        Snap's program files are protected against change. This is done by the process of mounting the protected files in their specific space as read only.



        The process also has specific space for configuration data which includes the user's specific home space (/home/user/snap) for data and configurations and a space for world-wide data (/var/snap).



        All the world-wide snap files are readable and accessible via symbolic links to the /snap area.



        You can verify the real location and how the spaces are linked with the following commands.



        A command to see examples of snap's protected mounts:



        $ mount | egrep snap | egrep ro,
        /var/lib/snapd/snaps/core_4486.snap on /snap/core/4486 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_185.snap on /snap/communitheme/185 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/hello-world_27.snap on /snap/hello-world/27 type squashfs (ro,nodev,relatime)
        /var/lib/snapd/snaps/core_4407.snap on /snap/core/4407 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_124.snap on /snap/communitheme/124 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/core_4571.snap on /snap/core/4571 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/communitheme_246.snap on /snap/communitheme/246 type squashfs (ro,nodev,relatime,x-gdu.hide)
        /var/lib/snapd/snaps/vlc_190.snap on /snap/vlc/190 type squashfs (ro,nodev,relatime,x-gdu.hide)


        A command to see examples of snap's spaces that are not write protected:



        $ mount | egrep snap | egrep -v ro,
        tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3293156k,mode=755)
        nsfs on /run/snapd/ns/hello-world.mnt type nsfs (rw)
        nsfs on /run/snapd/ns/vlc.mnt type nsfs (rw)


        By your error message you are trying to make change on files that have been programmably protected by the programmer. Your question suggests that you are the app's programmer. So you would have to use the features of snap's programming configuration to decide which files will be placed where.



        How can I resolve this?



        As I suggested in the comments, it would be safer and more common for you to design your program in a development environment as a normal user... normally in your own personal space, then use the snap's development system for installing the new version.



        I'm not a snap programmer and can't give exact specifics of how the designing and export for use process works with snap. But I can imagine it might be similar to designing Android, or Java programs, where the developer will use some type of export or publish method to run or to test the new version in an installed configuration.



        You could possibly experiment with remounting the protected read-only filesystems to read/write. I wouldn't advise it, because it might be possible to break the integrity of the snap system, or provide unexpected behavior where your application may not behave as intended because of the modification of the snap system itself.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered May 12 at 8:59









        L. D. James

        17.2k43077




        17.2k43077






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1035127%2fcannot-modify-files-installed-by-snap%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            pylint3 and pip3 broken

            Missing snmpget and snmpwalk

            How to enroll fingerprints to Ubuntu 17.10 with VFS491